On Thu, Dec 03, 2015 at 01:03:56AM -0000, John Levine wrote: > >> 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. ... > > >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. > > Yup, for the reasons I laid out, notably that there is no way other > than RFC 6186+DNSSEC to tell mechanically what servers handle what > mail domains. (I suppose it's possible I'm wrong, but if so, please > lay out the steps to use to get from a mail domain to a server name.) We're on the same page then. As I don't want to be the only one saying this, I am making an effort to let others say it first. > >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. > > I looked at RFC 6186, and don't see where it says that. Could you > clarify? It does say that the user will probably have to provide > login and password information, but that's a separate step after > deciding what server to use. https://tools.ietf.org/html/rfc6186#section-6 (second paragraph) A malicious attacker with access to the DNS server data, or able to get spoofed answers cached in a recursive resolver, can potentially cause MUAs to connect to any IMAP, POP3, or submission server chosen by the attacker. In the absence of a secure DNS option, MUAs SHOULD check that the target FQDN returned in the SRV record matches the original service domain that was queried. If the target FQDN is not in the queried domain, MUAs SHOULD verify with the user that the SRV --------------------------------------------- target FQDN is suitable for use before executing any connections to ------------------------------------------------------------------- the host. Alternatively, if TLS [RFC5246] is being used for the --------- email service, MUAs MUST use the procedure outlined in Section 6 of [RFC6125] to verify the service And the next sentence is clear as mud, alternative to what? In any case, absent DNSSEC validated SRV records, there is no good way to deploy transport security for *hosted* submission and imap services without users manually selecting the underlying provider hostnames as the service endpoint. With DNSSEC validated SRV records, one may as well use DANE. That said, DNSSEC is as yet not a ubiquitous viable option for mobile clients, we need many years of upgrades of public WiFi networks before one might be able to expect DNSSEC signed SRV records to reach one's mobile device. -- Viktor.