Re: [Uta] Review of draft-ietf-uta-email-deep-08

[Keith Moore <[e-mail]>]

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