On Wed, Dec 02, 2015 at 02:28:19PM -0000, John Levine wrote:
As I read that spec, it says mandatory to implement, not mandatory to
use (it's up to the application whether it claims to be capable of using
it or not) - but it permits servers to mandate its use. *Almost* there -
but if this draft wishes to mandate its use, it will have to say so (and
say which identifier it's going to send - AFAIK, it only gets to send one.)
Even with SNI, we still have the problem that there's no way for the
CA to tell what SRV-IDs it should sign other than using RFC 6186
lookups. But the MUA can do the same 6186 lookup, and that scales a
lot better for the many mail systems that handle large and changing
sets of client domains.
You're basically saying that WebPKI cannot provide security for
hosted email. Perhaps this is so. In which case transport security
for hosted email requires DNSSEC to do what WebPKI cannot.
Or are you suggesting "ask the user", or that the MUA just assume
that plain old DNS (not DNSSEC) is secure enough, and use the SRV
target hostname to check the peer certificate, despite the fact
that the SRV target name is trivial to MITM?
Basically, I don't how this draft changes the situation with respect
to the problems with 6186. My understanding of current practice
is that 6186 is not widely used, and the server names for IMAP,
SMTP, ... are explicitly configured, sometimes without asking the
user to specify them, because knowledge of the settings for user's
domain is wired into the MUA software.
My view (as noted in Section 7 of 7672) is that 6186 is defective
in that it glosses over a critical security issue by suggesting
asking the user to confirm data gleaned from SRV records. If the
user is in fact knowledgeable, and the settings are only obtained
once at account setup and hence remain frozen, this is roughly
similar to the situation with the baked-in settings for Gmail et.
al. in MUAs. In which case, one would use the frozen name as a
reference identifier for the server, since after the initial leap
of faith, it is a pinned "trusted" name.
This leaves the problem of making the pinned names "portable" (not
tied to the provider's domain). For that, the only sensible solution
is DANE. As you've noted CA's are very poorly positioned to able
to say anything about the authenticity of this type of arrangement.
--
Viktor.