Re: [Extra] Secdir last call review of draft-ietf-extra-imap4rev2-24

[Daniel Migault <[e-mail]>]

Hi Alexey,

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

Yours,
Daniel

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

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.

On 19/01/2021 14:52, Daniel Migault via Datatracker wrote:
> 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.
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?

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

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.

> </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.
Good point. I will remove TLS_RSA_WITH_AES_128_CBC_SHA from the document.
> [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.
Ok.
> </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
Thank you for the link, I will review.
> </mglt>
>
>     The list of mandatory-to-implement TLS 1.3 cipher suites is described
>     in Section 9.1 of [TLS-1.3].
>
  [snip]
>     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.

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>
ok, I agree this maybe the case for the client, but I expect the server to have its library being "specifically" configured.

</mglt>

> </mglt>
>
  [snip]
> 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.
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.
> 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.
Fair enough. Can you suggest some text?

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

> 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.
Can you give me an example, as I am not sure what do you mean by
injection in this case?

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

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

Best Regards,

Alexey