Last Call Review of draft-ietf-extra-imap4rev2-24

Request Review of draft-ietf-extra-imap4rev2
Requested rev. no specific revision (document currently at 30)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2021-01-20
Requested 2021-01-06
Authors Alexey Melnikov, Barry Leiba
Draft last updated 2021-01-19
Completed reviews Genart Last Call review of -24 by Robert Sparks (diff)
Secdir Last Call review of -24 by Daniel Migault (diff)
Assignment Reviewer Daniel Migault 
State Completed
Review review-ietf-extra-imap4rev2-24-secdir-lc-migault-2021-01-19
Posted at
Reviewed rev. 24 (document currently at 30)
Review result Has Nits
Review completed: 2021-01-19



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.



       Internet Message Access Protocol (IMAP) - Version 4rev2

[ ... ]

   $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
      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

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.  


[ ... ]

6.2.3.  LOGIN Command

   Arguments:  user name

   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.

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.   


   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.

I suspect there is an issue and that
TLS_RSA_WITH_AES_128_CBC_SHA  is instead

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. 


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
LS_RSA_WITH_AES_128_CBC_SHA256 was to keep
the number of cipher suites low. If that is
the case,
be a better fit at least in my opinion. 


   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_256_GCM_SHA384.  All other cipher suites are
   OPTIONAL.  Note that this is a change from section 2.1 of [IMAP-TLS].

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.  



   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

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. 


   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.

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.


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

   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.
   (2) Some other mechanism that protects the session from password
   snooping has been provided.
   (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
   (b) The LOGIN command returns an error even if the password is
   (c) The AUTHENTICATE command returns an error with all [SASL]
   mechanisms that use plaintext passwords, even if the password is

   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

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

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

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. 


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.