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.