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

["Chris Newman" <[e-mail]>]

On 25 Oct 2017, at 3:48, Keith Moore wrote:
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> I am balloting YES because I believe it is important to publish this. 
>> But there
>> are a few issues I think should be resolved first:
>>
>> Substantive:
>>
>> -2: There are several instances of lower case versions of 2119 
>> keywords. If
>> those are intentional, then please use the updated boilerplate from 
>> 8174.
>
> fixed in my draft of -10.
>
>> -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%.
>
>> -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>
>> -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.
>
>> -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.

Here's an attempt to reword without using the term "safely" which I 
agree is not ideal:

...  An MUA MUST NOT provide a client certificate during the
    TLS handshake unless the server requests one and the MUA has
    been authorized to use that client certificate with that account.
    Having the end-user explicitly configure a client certificate for 
use
    with a given account is sufficient to meet this requirement. 
However,
    installing a client certificate for use with one account MUST NOT
    automatically authorize use of that certificate with other accounts.
    This is not intended to prohibit site-specific authorization 
mechanisms,
    such as a site-administrator-controlled mechanism to authorize use 
of a
    client certificate with a given account, or a domain-name matching
    mechanism.

The issue is that some TLS libraries have a general pool of client 
certificates visible to the library (Mozilla NSS works this way, and I 
happen to like this design). Use of a client certificate with the wrong 
server causes both privacy and interoperability problems. There's 
presently no standardized mechanism that an TLS client library can use 
to identify a particular client certificate as authorized for use with a 
given server. On the flip site, requiring explicit end-user 
configuration of a client certificate with each account adds to the 
already user-hostile experience of client certificates. We really want 
to allow more user-friendly mechanisms to authorize use of a client 
certificate with a given account, so we need a rule that protects 
privacy/interoperability but doesn't prohibit UI innovation. I'm open to 
suggestions for better wording.

		- Chris

>> Editorial:
>>
>> - Abstract: Please mention the updated RFCs
> is it conventional to do so, given that the Updates: heading should be 
> present?
>> -4: "The following practices are recommended "
>> There are some MUSTs in those practices. That makes them required, 
>> not merely
>> recommended.
>
> ok
>> -4, first and third bullets: s/ which / that
> ok
>> -4.1, first paragraph: The two "MAYs" seem more like statements of 
>> fact.
>
> Uppercase MAY is deliberate.   Those statements are intended to 
> explicitly give latitude to operators.
>> -5, 3rd bullet: "MUAs MUST NOT consider "
>> s/consider/treat   (unless we are talking about humans are AIs :-)  )
> ok
>
> Thanks for the careful review.
>
> Keith