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. 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 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. 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 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. 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]. 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 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]. 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 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. 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. 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.