Subject: [secdir] Secdir last call review of draft-ietf-extra-imap4rev2-24

From: Daniel Migault via Datatracker <[email-masked]>
Date: Tue, 19 Jan 2021 06:52:05 -0800

Reviewer: Daniel Migault
Review result: Has Nits

Hi, 

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is: Ready though I found some nits in 
the security consideration.  

Please find my comments/ questions below.

Yours, 
Daniel

       Internet Message Access Protocol (IMAP) - Version 4rev2
                     draft-ietf-extra-imap4rev2-24

[ ... ]

   $Phishing  The $Phishing keyword can be used by a delivery agent to
      mark a message as highly likely to be a phishing email.  An email
      that's determined to be a phishing email by the delivery agent
      should also be considered a junk email and have the appropriate
      junk filtering applied, including setting the $Junk flag and
      placing in the \Junk special-use mailbox (see Section 7.2.3) if
      available.
      If both the $Phishing flag and the $Junk flag are set, the user
      agent should display an additional warning message to the user.
      User agents should not use the term "phishing" in their warning
      message as most users do not understand this term.  Phrasing of
      the form "this message may be trying to steal your personal
      information" is recommended.  Additionally the user agent may
      display a warning when clicking on any hyperlinks within the
      message.

<mglt>
I tend to believe that phishing is now
(unfortunately) known by most users. 
I have the impression that UI is always a
difficult problem, and I am wondering if such
recommendations are still valid or if that is
a legacy statement. I do not have strong
feeling about what to do, so I leave it to
you, but is interested in your opinion.  

</mglt>

[ ... ]

6.2.3.  LOGIN Command

   Arguments:  user name
               password

   Responses:  no specific responses for this command

   Result:     OK - login completed, now in authenticated state
               NO - login failure: user name or password rejected
               BAD - command unknown or arguments invalid

   The LOGIN command identifies the client to the server and carries the
   plaintext password authenticating this user.

   A server MAY include a CAPABILITY response code in the tagged OK
   response to a successful LOGIN command in order to send capabilities
   automatically.  It is unnecessary for a client to send a separate
   CAPABILITY command if it recognizes these automatic capabilities.

Melnikov & Leiba          Expires July 9, 2021                 [Page 32]

Internet-Draft                  IMAP4rev2                   January 2021

      Example:    C: a001 LOGIN SMITH SESAME
                  S: a001 OK LOGIN completed

   Note: Use of the LOGIN command over an insecure network (such as the
   Internet) is a security risk, because anyone monitoring network
   traffic can obtain plaintext passwords.  The LOGIN command SHOULD NOT
   be used except as a last resort, and it is recommended that client
   implementations have a means to disable any automatic use of the
   LOGIN command.

<mglt>
For my personal information.  It is unclear
to me why the LOGIN command is SHOULD NOT and
not MUST NOT. I am mostly likely missing
something, but my impression was so far that
STARTTLS was mandatory. I suppose that "a
configuration" means that it is not always
the case, but then it becomes unclear to me
why we would have STARTTLS in one
configuration but not the other. This sounds
to me that we are sort of allowing a
vulnerable configuration as long the server
may be accessed with a secure configuration.
I think I am missing some dots.   

</mglt>

   Unless either the client is accessing IMAP service on IMAPS port
   [RFC8314], the STARTTLS command has been negotiated or some other
   mechanism that protects the session from password snooping has been
   provided, a server implementation MUST implement a configuration in
   which it advertises the LOGINDISABLED capability and does NOT permit
   the LOGIN command.  Server sites SHOULD NOT use any configuration
   which permits the LOGIN command without such a protection mechanism
   against password snooping.  A client implementation MUST NOT send a
   LOGIN command if the LOGINDISABLED capability is advertised.

[... ]

11.  Security Considerations

   IMAP4rev2 protocol transactions, including electronic mail data, are
   sent in the clear over the network unless protection from snooping is
   negotiated.  This can be accomplished either by the use of IMAPS
   service, STARTTLS command, negotiated privacy protection in the
   AUTHENTICATE command, or some other protection mechanism.

11.1.  STARTTLS Security Considerations

   IMAP client and server implementations MUST comply with relevant TLS
   recommendations from [RFC8314].

Melnikov & Leiba          Expires July 9, 2021                [Page 143]

Internet-Draft                  IMAP4rev2                   January 2021

   Clients and servers MUST implement TLS 1.2 [TLS-1.2] or newer.  Use
   of TLS 1.3 [TLS-1.3] is RECOMMENDED.  TLS 1.2 may be used only in
   cases where the other party has not yet implemented TLS 1.3.
   Additionally, when using TLS 1.2, IMAP implementations MUST implement
   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite, and SHOULD
   implement the TLS_RSA_WITH_AES_128_CBC_SHA [TLS-1.2] cipher suite.

<mglt>
I suspect there is an issue and that
TLS_RSA_WITH_AES_128_CBC_SHA  is instead
TLS_RSA_WITH_AES_128_CBC_SHA256.

However, these suites are not set as
"recommended" on the IANA registry.  Note
that the term recommended may be misleading
as it does not necessarily means the cipher
is weak. It means instead that the cipher
suite has not been through a standard
process.  This could mean, for example, the
cipher suite may correspond to a specific use
case. If that is the case, I believe that
should be mentioned.  However, I believe that
in this case, the motivation for the
community is that RSA authentication suffers
from a significant number of attacks - [1],
no forward secrecy - and I tend to believe
its support may not be recommended. RFC7525
for example mentions it as SHOULD NOT. 

[1] https://www.usenix.org/conference/usenixsecurity18/presentation/bock

In order to defer the cryptographic
recommendations to RFC8447, and ensure these
recommendations to be update to date, I would
reference that the TLS client and server are
expected to follow RFC8447 for their
cryptographic recommendations. Currently
RFC8847 sets a cipher suite as recommended
when it has received a wide support from the
community and it intend is as far as I think
to remove ciphers that will become weak.

RFC8447 works for TLS 1.2 and 1.3  keeps the
number of cipher suites relatively low, so if
the motivation to mandate
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and
LS_RSA_WITH_AES_128_CBC_SHA256 was to keep
the number of cipher suites low. If that is
the case,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 may
be a better fit at least in my opinion. 

</mglt>

   This is important as it assures that any two compliant
   implementations can be configured to interoperate.  Other TLS cipher
   suites recommended in RFC 7525 are RECOMMENDED:
   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
   TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and
   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.  All other cipher suites are
   OPTIONAL.  Note that this is a change from section 2.1 of [IMAP-TLS].

<mglt>
I believe this is good to mention RFC7525 for
TLS 1.2. There might small overlap concerning
cipher recommendations with RFC8447, but
RFC7525 recommendations go beyond and is not
limited to cipher suites recommendations. 

Regarding the RSA versus ECDSA it seems to me
that RSA is a bit behind. [1] mentions ECDSA
and RSA in their intermediate profile with
ECDSA recommended. I would maybe avoid
explicitly recommend these cipher suites, and
if that is needed, I would explain why these
are recommended.  

[1] https://wiki.mozilla.org/Security/Server_Side_TLS

</mglt>

   The list of mandatory-to-implement TLS 1.3 cipher suites is described
   in Section 9.1 of [TLS-1.3].

   During the TLS negotiation [TLS-1.3][TLS-1.2], the client MUST check
   its understanding of the server hostname against the server's
   identity as presented in the server Certificate message, in order to
   prevent man-in-the-middle attacks.  This procedure is described in
   [RFC7817].

<mglt>
I think it would be good to mention DANE as
well as certificate checks.  

In addition, when TLS 1.3 is used, the client
and the server MAY also enabled the
ticket_pinning extension [RFC8672] to further
prevent and detect man-in-the-middle attacks.
The ticket_pinning extensions provides
evidence that after an initial TLS session,
the subsequent TLS sessions are performed
with the same TLS server, as well as - when
such attacks occurs - detect them on both
client or server side. For full disclosure I am 
co-authoring identity pinning. 

</mglt>

   Both the client and server MUST check the result of the STARTTLS
   command and subsequent TLS ([TLS-1.3][TLS-1.2]) negotiation to see
   whether acceptable authentication and/or privacy was achieved.

<mglt>
This is a bit unclear to me as I do not
expect to have a server / client accepting
cipher_suites, or being configured to
establish a TLS session that does not achieve
what we expect. In other word, I understand
the paragraph as saying after the
session establishment, we recheck that
parameters chosen are appropriated. I suppose
I am missing something, but if not I would
have expected it to be the other way around.

</mglt>

11.2.  COPYUID and APPENDUID response codes

   The COPYUID and APPENDUID response codes return information about the
   mailbox, which may be considered sensitive if the mailbox has
   permissions set that permit the client to COPY or APPEND to the
   mailbox, but not SELECT or EXAMINE it.

   Consequently, these response codes SHOULD NOT be issued if the client
   does not have access to SELECT or EXAMINE the mailbox.

11.3.  LIST command and Other Users' namespace

   In response to a LIST command containing an argument of the Other
   Users' Namespace prefix, a server SHOULD NOT list users that have not
   granted list access to their personal mailboxes to the currently
   authenticated user.  Providing such a list, could compromise security
   by potentially disclosing confidential information of who is located
   on the server, or providing a starting point of a list of user
   accounts to attack.

Melnikov & Leiba          Expires July 9, 2021                [Page 144]

Internet-Draft                  IMAP4rev2                   January 2021

11.4.  Other Security Considerations

   A server error message for an AUTHENTICATE command which fails due to
   invalid credentials SHOULD NOT detail why the credentials are
   invalid.

   Use of the LOGIN command sends passwords in the clear.  This can be
   avoided by using the AUTHENTICATE command with a [SASL] mechanism
   that does not use plaintext passwords, by first negotiating
   encryption via STARTTLS or some other protection mechanism.

   A server implementation MUST implement a configuration that, at the
   time of authentication, requires:
   (1) The STARTTLS command has been negotiated.
   OR
   (2) Some other mechanism that protects the session from password
   snooping has been provided.
   OR
   (3) The following measures are in place:
   (a) The LOGINDISABLED capability is advertised, and [SASL] mechanisms
   (such as PLAIN) using plaintext passwords are NOT advertised in the
   CAPABILITY list.
   AND
   (b) The LOGIN command returns an error even if the password is
   correct.
   AND
   (c) The AUTHENTICATE command returns an error with all [SASL]
   mechanisms that use plaintext passwords, even if the password is
   correct.

   A server error message for a failing LOGIN command SHOULD NOT specify
   that the user name, as opposed to the password, is invalid.

   A server SHOULD have mechanisms in place to limit or delay failed
   AUTHENTICATE/LOGIN attempts.

   Additional security considerations are discussed in the section
   discussing the AUTHENTICATE (see Section 6.2.2) and LOGIN (see
   Section 6.2.3) commands.

<mglt>
Another concern regarding
authentication with IMAP is user have usually
one account and one login/password for a
cloud account as well as an IMAP account. In
many cases, the cloud account provides 2FA
which makes possession of the login password
not sufficient to gain access. However, IMAP
authentication hardly provide 2FA, and mail
may not benefit from the same protection and
could be used to escape 2FA. I believe this
could be mentioned as well as known
mechanisms to provide 2FA with IMAP - if 
there are some.  

Note that 2FA may not necessarily prevent to
guess the correspondence between login and
password.  

The section mentions that repeated attempts
for a password associated is detected,
somehow prevented. It may also worth
mentioning that with a large number of login
(known or guessed),
an attacker may try to guess a login
associated to a small number of commonly
known weak passwords ( password
spraying). I believe it might worth being
mentioned, that correlating failed attempts
worth also being mentioned.  
Maybe that goes a bit too far in the purpose
of recommendations, but it might may sense to
recommend strong random passwords used in
conjunction of passwords wallets or the use
of mutually authenticate TLS. 

</mglt>

<mglt>
One question I would have - and with very
little opinion on it - is how vulnerable IMAP
parsing is to injection. I usually see the
use of JSON as a big advantage toward 
this, but I would be happy to known 
your opinion on it. 

I also have the impression that injections
can be performed via the web interface, so a
web front end should be carefully considered
and IMAP server may not believe they are
always immune behind a web front end and
still require to follow the best practises.  

</mglt>

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 19 Jan 2021 17:46:08 +0000

Hi Daniel,

Thank you for your review. My replies below. I removed some of your 
comments that I need to think a bit more and will reply to them separately.

> you, but is interested in your opinion.
This text matches the original registration of the $Phishing keyword. I 
have seen some modern email clients still following this advice, so I 
think it is useful. Which part of it do you find outdated?
> I think I am missing some dots.

Thank you for drawing my attention to this. I agree that the text is 
wrong. I think the intent was to allow LOGIN on "secure networks" and 
disallow it otherwise. After rereading this the quoted paragraph is not 
saying that. I will fix.

> for example mentions it as SHOULD NOT.
Good point. I will remove TLS_RSA_WITH_AES_128_CBC_SHA from the document.
> [1]https://www.usenix.org/conference/usenixsecurity18/presentation/bock
>
>
>
Ok.
> [1]https://wiki.mozilla.org/Security/Server_Side_TLS
Thank you for the link, I will review.
>     in Section 9.1 of [TLS-1.3].
  [snip]
> have expected it to be the other way around.

I don't think all implementations control cipher suites to be used 
before negotiation starts (this might be API and/or implementation 
limitation), so this is encouraging to check whether negotiated 
ciphersuite matches policy after negotiation completes.

> </mglt>
  [snip]
> mechanisms to provide 2FA with IMAP - if
There are some drafts adding 2FA to SASL authentication that are likely 
to be discussed in the KITTEN WG. But at this point there is nothing 
that can be referenced normatively. I will think what can be said about 
that.
> worth also being mentioned.
Fair enough. Can you suggest some text?
> this, but I would be happy to known
Can you give me an example, as I am not sure what do you mean by 
injection in this case?
> still require to follow the best practises.

Best Regards,

Alexey

---

From: Daniel Migault <[email-masked]>
Date: Tue, 19 Jan 2021 20:46:37 +0000

Hi Alexey,

Thanks for your response. Please find some clarifications/responses.

Yours,
Daniel

________________________________
From: Alexey Melnikov <[email-masked]>
Sent: Tuesday, January 19, 2021 12:46 PM
To: Daniel Migault <[email-masked]>; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: Secdir last call review of draft-ietf-extra-imap4rev2-24

Hi Daniel,

<mglt>

Just to be clear that was just a comment. In the following sentence,
"""
User agents should not use the term "phishing" in their warning
message as most users do not understand this term.
"""
I was questioning  "as most users do not understand this term" and tend to believe that most users have heard what phishing means. So I am wondering if the user the message is being shown does not translate to itself: "Oh yeah they mean phishing".  Again just some random thoughts from my part.

</mglt>

Ok.
  [snip]

<mglt>
ok, I agree this maybe the case for the client, but I expect the server to have its library being "specifically" configured.

</mglt>

  [snip]

<mglt>
Maybe something around these lines:

An IMAP server SHOULD report any authentication failure and analyze the attempt with regard to a password brute force attack as well as a password spraying attack. Accounts that matching password spraying attacks MUST be blocked and request to change their passwords and only password with significant strength SHOULD be accepted.
</mglt>

<mglt>
I do not have specific example in mind. My question was if there are known ways to inject some commands in a specific field or if some parsers checks have been relaxed to enable interoperability.

</mglt>

Best Regards,

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 20 Jan 2021 17:31:07 +0000

Hi Daniel,

> Thanks for your response. Please find some clarifications/responses.
Thank you for the followup. My responses below.
>
> Yours,
> Daniel
>
> ------------------------------------------------------------------------
> *From:* Alexey Melnikov <[email-masked]>
> *Sent:* Tuesday, January 19, 2021 12:46 PM
> *To:* Daniel Migault <[email-masked]>; [email-masked] 
> <[email-masked]>
> *Cc:* [email-masked] 
> <[email-masked]>; [email-masked] 
> <[email-masked]>; [email-masked] <[email-masked]>
> *Subject:* Re: Secdir last call review of draft-ietf-extra-imap4rev2-24
> Hi Daniel,
>
  [snip]
> I was questioning  "as most users do not understand this term" and 
> tend to believe that most users have heard what phishing means. So I 
> am wondering if the user the message is being shown does not translate 
> to itself: "Oh yeah they mean phishing".  Again just some random 
> thoughts from my part.
Sorry, I was staring at this text so much that I stopped noticing it. 
Now that you pointed this out I think removing this sentence makes sense.
  [snip]
> An IMAP server SHOULD report any authentication failure and analyze 
> the attempt with regard to a password brute force attack as well as a 
> password spraying attack. Accounts that matching password spraying 
> attacks MUST be blocked and request to change their passwords and only 
> password with significant strength SHOULD be accepted.
I edited this slightly. Thank you for the suggestion.
> /**/
> I do not have specific example in mind. My question was if there are 
> known ways to inject some commands in a specific field or if some 
> parsers checks have been relaxed to enable interoperability.
I can't think of any. IMAP is either using octet-counted literals or 
strict syntax (LIST-like). Syntax is quite regular and easier than XML 
(IMHO).

---

From: Daniel Migault <[email-masked]>
Date: Wed, 20 Jan 2021 18:22:16 +0000

Thanks for the response!
Yours,
Daniel
Sent: Wednesday, January 20, 2021 12:31 PM

Hi Daniel,

Yours,
Daniel

________________________________
From: Alexey Melnikov <[email-masked]><mailto:[email-masked]>
Sent: Tuesday, January 19, 2021 12:46 PM
To: Daniel Migault <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: Secdir last call review of draft-ietf-extra-imap4rev2-24

Hi Daniel,

 [snip]

<mglt>

Sorry, I was staring at this text so much that I stopped noticing it. Now that you pointed this out I think removing this sentence makes sense.

</mglt>
 [snip]

<mglt>

<mglt>
I do not have specific example in mind. My question was if there are known ways to inject some commands in a specific field or if some parsers checks have been relaxed to enable interoperability.
I can't think of any. IMAP is either using octet-counted literals or strict syntax (LIST-like). Syntax is quite regular and easier than XML (IMHO).

</mglt>

Best Regards,

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 24 Jan 2021 12:50:56 +0000

Hi Daniel,

  [snip]

> well as certificate checks.

This came up before, but at this point there is no document describing 
how to use DANE with email clients (an alternative/update to RFC 7817) 
and I am not aware of any client implementations that use DANE 
experimentally for this.

Best Regards,

Alexey