>> 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.) Imagine you had a shared web server that hosted 50,000 different domains with 50,000 different certificates. The domains are all owned by different people, so each one has to arrange to sign its own certificate and provide it to the server operator in a suitably secure way. That's essentially the situation with a large SUBMIT or POP/IMAP server. >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? No, I'm saying that there is no way other than RFC 6186+DNSSEC to tell mechanically what servers handle what mail domains. >Basically, I don't how this draft changes the situation with respect >to the problems with 6186. It doesn't. But since there is no way other than RFC 6186+DNSSEC to tell mechanically what servers handle what mail domains, that's all we've got. >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. R's, John