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