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

[Alexey Melnikov <[e-mail]>]

Hi Keith,
Quickly answering to a few easy ones:

On 25/07/2017 05:18, Keith Moore wrote:
> 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.

That would be great.

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

This looks good to me.


 (snip)

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

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

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

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