Hi Alexey,
Thanks for the review! Some responses:
On 07/24/2017 12:04 PM, Alexey Melnikov wrote:
I am generally very pleased with -07 and -08.
A few minor comments:
1. Introduction
This memo does not address use of TLS with SMTP for message relay
(where Message Submission [RFC6409] does not apply). Improved use of
TLS with SMTP for message relay requires a different approach. One
approach to address that topic is described in [RFC7672].
I think you should also reference MTA STS draft informatively here.
I'm personally okay with doing that.
4.1. Deprecation of Services Using Cleartext and TLS Versions < 1.1
The specific means employed for deprecation of cleartext Mail Access
Services and Mail Submission Services this MAY vary from one MSP to
Extraneous "this" above.
the next in light of their user communities' needs and constraints.
Later in the same section:
Also, users authenticating with passwords SHOULD be required to
change those passwords when migrating from cleartext to TLS, since
the old passwords were likely to have been compromised.
Not necessarily true with something like SCRAM or GSSAPI (if PLAIN is
also disabled), but I don't know how to word this better. I.e.
authentication might still not expose the password without TLS.
How about:
Also, users previously authenticating with passwords sent as cleartext
SHOULD be required to change those passwords when migrating to TLS,
since the old passwords were likely to have been compromised.
Transition of users from SSL or TLS 1.0 to later versions of TLS MAY
be accomplished by a means similar to that described above. There
are multiple ways to accomplish this. One way is for the server to
refuse a ClientHello message from any client sending a protocol
version number corresponding to any version of SSL or TLS 1.0.
I don't think this is quite right: my understanding is that client can
send such versions (for backward compatibility), but end up
negotiating TLS 1.2.
The version number that the client sends in ClientHello is the /maximum/
version number that the client will support. The server is free to
offer a lower version number in its ServerHello response, which the
client can accept (by continuing the session) or reject (by closing it).
So the advice here should be that neither the server nor the client
can negotiate SSL 2.0/TLS 1.0.
Even SSL 2.0 is better than cleartext. It just doesn't meet minimum
confidentiality requirements. If the MUA's configuration for that
account doesn't impose minimum confidentiality requirements, the MUA is
free to accept a ServerHello message offering an obsolete and insecure
protocol version, because it would have presumably accepted cleartext
anyway. The MUA just shouldn't represent to the user that that
connection is secure.
Another way is for the server to accept ClientHello messages from
some client versions that it does not wish to support, but later
refuse to allow the user to authenticate. The latter method may
provide a better indication to the user of the reason for the failure
but (depending on the protocol and method of authentication used) may
also risk exposure of the user's password over an channel which is
known to not provide adequate confidentiality.
5.2. Minimum Confidentiality Level
MUAs SHOULD NOT allow users to "click through" to access or send mail
It is not clear to me whether you are recommending better UI or a UI
that doesn't allow the user to bypass this?
The intent is that the MUA shouldn't offer a popup or similar dialog to
allow a user to /easily/ bypass the account's minimum confidentiality
requirements. It's too easy to do this by accident, or without the
user reading or understanding the MUA's description of the situation.
And often, it's not just a few email messages that are compromised by
doing so - it's the user's credentials and by extension all of the
user's saved and future email, and potentially also any other resources
that use that same password. So it's a big deal.
If the user wants to reconfigure a mail account to not impose the
minimum confidentiality requirement, that's up to the user, but "click
through" is just a Bad Idea.
via an connection, or to authenticate to any service using a
password, if that account is configured to impose minimum
confidentiality requirements and that connection does not meet all of
those requirements. Experience indicates that users presented with
such an option often "click through" without understanding the risks
that they're accepting by doing so.
5.4. Certificate Pinning
A pinned certificate is subject to a man-in-the-middle attack at
account setup time, and lacks a mechanism to revoke or securely
refresh the certificate.
Isn't this a MUA UI issue? I.e., a MUA may allow users to manage
pinned certificates.
Use of pinned certs isn't forbidden by the draft, but pinned certs don't
meet minimum confidentiality requirements.
I think it might be possible to adequately address the security concerns
associated with the usual implementation of pinned certificates, but
working though the details seems beyond the scope of this document.
5.5. Client Certificate Authentication
MUAs MAY implement client certificate authentication on the Implicit
TLS port. An MUA MUST NOT provide a client certificate during the
"MUST NOT" sounds too strong. Why?
TLS handshake unless the server requests one and the client has
determined the certificate can be safely used with that specific
server, OR the client has been explicitly configured by the user to
use that particular certificate with that server. How to make this
determination is presently implementation specific.
I think this is Chris' text, so I'll let him answer.
I do seem to recall from long ago that TLS 1.0 at least had a flaw that
if a client has multiple certs it could potentially use, the protocol
gives the client no idea as to which of those certs to use - and
presumably only one will work. If the client presents the wrong one,
the AUTH EXTERNAL could fail, and the client wouldn't know why. So the
client requires specific configuration to know which certificate to use
with which server.
Forgive me for not knowing this off the top of my head, but was this
flaw ever fixed?
8. Security Considerations
It could be argued that sharing the name and version of the client
software with the server has privacy implications.
You should probably mention IMAP ID extension (RFC 2971) here, as well
as other known mechanisms.
I think this text may be left over from the STS stuff, so maybe we don't
need it anymore.
Keith
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
