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

From: Ben Campbell <[email-masked]>
Date: Tue, 24 Oct 2017 20:00:39 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-uta-email-deep-09: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-uta-email-deep/

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

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

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

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

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

Editorial:

- Abstract: Please mention the updated RFCs

-4: "The following practices are recommended "
There are some MUSTs in those practices. That makes them required, not merely
recommended.

-4, first and third bullets: s/ which / that

-4.1, first paragraph: The two "MAYs" seem more like statements of fact.

-5, 3rd bullet: "MUAs MUST NOT consider "
s/consider/treat   (unless we are talking about humans are AIs :-)  )

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Oct 2017 06:48:37 -0400

fixed in my draft of -10.

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

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

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

> - Abstract: Please mention the updated RFCs
is it conventional to do so, given that the Updates: heading should be 
present?
> There are some MUSTs in those practices. That makes them required, not merely

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.
> s/consider/treat   (unless we are talking about humans are AIs :-)  )
ok

Thanks for the careful review.

Keith

---

From: Ben Campbell <[email-masked]>
Date: Wed, 25 Oct 2017 13:48:46 -0500

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

[…]

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

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

That works for me.

> I don't believe the current language allows for click-through overrides for invalid certificates - the text explicitly says :
> 
> 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.

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

---

From: "Chris Newman" <[email-masked]>
Date: Thu, 26 Oct 2017 15:44:58 -0700

On 25 Oct 2017, at 3:48, Keith Moore wrote:
> 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.
>
> 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%.
>
> 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:
>
> I don't believe the current language allows for click-through 
> overrides for invalid certificates - the text explicitly says :
>
> 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.
>
> 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 
> 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.
>

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 26 Oct 2017 22:21:03 -0500

> On Oct 26, 2017, at 5:44 PM, Chris Newman <[email-masked]> wrote:
> 
> Here's an attempt to reword without using the term "safely" which I agree is not ideal:
> 
>   Having the end-user explicitly configure a client certificate for use
>   with a given account is sufficient to meet this requirement. However,
>   This is not intended to prohibit site-specific authorization mechanisms,
>   such as a site-administrator-controlled mechanism to authorize use of a
> 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.
> 

That’s more clear, thanks!

Ben.