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