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

[Keith Moore <[e-mail]>]

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

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