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>
[ ... ]
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>
[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?
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?
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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
