Re: [Uta] Ben Campbell's Yes on draft-ietf-uta-email-deep-09: (with COMMENT)

[Ben Campbell <[e-mail]>]

> On Oct 25, 2017, at 5:48 AM, Keith Moore <[e-mail]> wrote:
> 

[…]

> 
>> -4.1, last paragraph: "It is RECOMMENDED that new users be required to use TLS
>> version 1.1
>>    or greater from the start."
>> Is 1.1 correct? Why not start with 1.2?
> 
> TLS 1.1 was a deliberate choice.  Reality is that some new users will still be using old mail user agents, and there are often other factors that impair users' ability to upgrade.   If new users were _required_ to use TLS 1.2, that would essentially prevent them from getting new email service, or maybe force them to spend large amounts of money for new hardware and/or software in order to do so.  Either that or mail service providers might legitimately claim that they had good reason to take exception to the RECOMMENDED keyword and the paragraph would have no beneficial effect.
> 
> It's basically a judgment call - what policy on the part of mail service providers results in the best security overall?   It appears possible to err on the side of either too strict or too loose.
> 
> That said, some of the text in this draft is three years old, and conditions have changed somewhat in that interval.   If 99% of deployed user agents implement TLS 1.2, requiring 1.2 for new users would probably not bother me.  But if the figure were closer to 90%, it would bother me.   Maybe someone has actual figures, but I suspect the actual level of deployment is still well less than 90%.

I’m convinced. A sentence or two of explanation in the text might be helpful.


> 
>> -5, bullet starting with: MUAs SHOULD provide a prominent visual indication "
>> This section seems to merit a MUST NOT level requirement about displaying the
>> visual indication without sufficient evidence of confidentiality.
> 
> Hmm.   I'm probably okay with that in principle.   The problem I have with it is that the draft (appropriately IMO) gives MUA implementors latitude as to what indications to assign to what levels of confidentiality.   I am not immediately sure how to reconcile that decision with a MUST NOT requirement that denies implementors that latitude.   But I took a stab at it:
> 
>     <t>MUAs SHOULD provide a prominent indication of the level of
>     confidentiality associated with an account configuration that is
>     appropriate for the user interface (for example, a "lock" icon or
>     changed background color for a visual interface, or some sort of
>     audible indication for an audio user interace), at appropriate
>     times and/or locations in order to inform the user of the
>     confidentiality of the communications associated with that
>     account.  For example, this might be done whenever (a) prompting
>     the user for authentication credentials, (b) the user is composing
>     mail that will be sent to a particular submission server, (c) a
>     list of accounts is displayed (particularly if the user can select
>     from that list to read mail), or (d) the user is requesting to
>     view or update any configuration data that will be stored on a
>     remote server.  If, however, an MUA provides such an indication,
>     it MUST NOT indicate confidentiality for any connection that does
>     not at least use TLS 1.1 with certificate verification and also
>     meet the minimum confidentiality requirements configured for that
>     account.</t>

That works for me.

>> -5.4: I'm confused at why certificate pinning is okay for explicitly invalid
>> certificates, when click-through overrides were previously recommended against.
>> It seems like the same level of abuse is likely. (It's one thing to allow a
>> user to set policy for an invalid cert; it's another to prompt them to do so.)
> 
> I don't believe the current language allows for click-through overrides for invalid certificates - the text explicitly says :
> 
>     Certificate pinning is only appropriate during mail account
>     setup and MUST NOT be offered as an option in response to a failed
>     certificate validation for an existing mail account.
> 
> Offhand, the current compromise seems about right to me - yes, you can tell your MUA to use a certificate that is self-signed, expired, or has a name that doesn't match the DNS name used during account configuration; but the MUA isn't allowed (MUST NOT) to prompt you to let you access your account anyway if the certificate is invalid and the account wasn't already explicitly configured to permit such access.

I understand that we are talking about account configuration time, not later access, and I especially understand the need to let users configure self-signed certs, or certs where they don’t trust the CA. (I’m not quite sure about “expired”, but I will leave that to others.)

But am concerned that if the MUA pops a dialog during account setup that basically says “This certificate has issues, do you want to use it anyway” will result in a lot of users clicking “yes” without reading the details. I don’t really know the answer, and I’m certainly not a UX expert. But I wonder if it might be better to say that an MUA can allow a user to set per-account policy to allow this sort of thing, but not suggest that the MUA actively offer to do that.

In any case, this is not a blocking comment—I will trust the authors and WG to figure the right compromise.


> 
>> -5.5: How would a client determine that a client cert could be safely used with
>> a particular server? (What does "safely" mean in this context?)
> Good point.  This is Chris's text so I'm not entirely sure what his concern was.  My guesses are: (a) there's a privacy risk associated with disclosing a client cert with one identity to a server that might know the user by a different identity; and (b) if for whatever reason the server doesn't like the client cert, it might deny access to the mail account even though it would have granted access based on the other credentials presented by the user in POP/IMAP/Submission authentication.   But offhand I don't know how the client could know when using the client cert is "safe" other than by having been explicitly configured to do so.  Even "it has worked in the past" might not be good enough because the cert could have expired or been revoked, or the server changed its policies, since then.
> 
> My inclination is to remove the "client has determined that the certificate can be safely used" clause, but I'd like to see what Chris suggests here.

I’m okay either way, but if it does stay in it would be helpful to include the explanation.

[…]

Thanks!

Ben.