1. I especially appreciate this document being expressed as deltas to
RFC 8314, as I believe this makes it much easier for a reader
(especially an implementor or mail service operator) to understand
exactly what's being changed.
2. For existing accounts that have already been established between an
MUA and a mail service, should updated MUAs that follow these revised
recommendations continue to regard TLS 1.1 as providing the minimum
confidentiality level? Or should such MUAs now warn users that these
services no longer provide adequate confidentiality? Or are there
specific server profiles (e.g. certain ciphersuites) of TLS 1.1 that
still provide adequate confidentiality which can be detected by the client?
IMO there is a delicate compromise to be made between:
- encouraging service operators to upgrade their security,
- not encouraging users to worry needlessly about security risks that
don't actually exist, and especially,
- not conditioning users to ignore security warnings because they're too
frequently present.
So when an updated MUA uses an existing account configuration to make a
connection with a server that supports TLS 1.1 at most, IMO it should
still regard that connection as providing minimum confidentiality as
long as there's no reason to believe that the connection is insecure.
(Updated MUAs will still flag newly established connection to that
server as not having minimum confidentiality, so operators still have
some incentive to .)
However if the TLS 1.1 connection (for example) is using a ciphersuite
now known to be insecure, an updated MUA should begin to flag those
connections as no longer having minimum confidentiality.
(The theory that I have is that if security warnings to users are
consistently accurate and provide a warning of severity that is
proportionate to the threat, users will learn to treat them as credible.)
Keith
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
