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

From: Alexey Melnikov <[email-masked]>
Date: Mon, 24 Jul 2017 17:04:27 +0100

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

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Jul 2017 00:18:20 -0400

Hi Alexey,

Thanks for the review!  Some responses:

> I think you should also reference MTA STS draft informatively here.

I'm personally okay with doing that.
> 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.

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

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

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

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

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 25 Jul 2017 07:56:10 +0100

Hi Keith,
Quickly answering to a few easy ones:

> I'm personally okay with doing that.

That would be great.

> since the old passwords were likely to have been compromised.

This looks good to me.

 (snip)

> that use that same password.   So it's a big deal.

I agree with you. I just think that the text might need a bit clarification.

> working though the details seems beyond the scope of this document.

Ok, how about inserting "typically" before "lacks a mechanism to revoke
...". This way you are making an observation about state of UIs without
sounding like it is a fact of nature.

Best Regards,
Alexey

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Jul 2017 07:07:51 -0400

> sounding like it is a fact of nature.
I'm thinking more along the lines of "there is currently no protocol 
defined for revocation of a pinned certificate".

TOFU isn't entirely good or evil, though it does provide a vulnerability 
that will certainly be exploited.  (We're creating a similar 
vulnerability by encouraging use of unsigned SRV records to dictate 
account configuration parameters, which seems hard to fix at the moment 
given how hard it is to deploy DNSSEC.   Maybe DNS-over-TLS will emerge 
as a way to double-check the validity of those SRV records.)

Keith