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 _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
