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.
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.
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.
So the advice here should be that neither the server nor the client can
negotiate SSL 2.0/TLS 1.0.
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?
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.
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.
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.
Best Regards,
Alexey
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
