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