Tony Finch wrote:
STARTTLS as it is currently used is fine for message submission, but it
could do with a more precise specification.
For inter-domain SMTP, STARTTLS is hopeless because the majority of MX
server certificates cannot be verified, as Carl has previously described
on this list http://www.imc.org/ietf-smtp/mail-archive/msg05366.html
I think the situation has improved slightly. All of the Fortune 500
domains I'd identified in 2008 as having unverifiable certificates have
since been fixed. I'm also seeing more customer interest in more robust
TLS deployments, particular from the Federal Government.
So we need something that allows MXs to say explicitly, "please strictly
verify my certificate". For this to be any use it needs downgrade
prevention, which probably requires a declaration in the DNS protected
with DNSSEC.
There is also the problem of which identity is to be verified. There is no
point verifying the MX target host name unless the recipient's DNS zone is
signed and the sender's MTAs are doing DNSSEC validation.
I think that latter element as it the heart of the DANE working group?
(No, I hadn't heard of that WG until Dave pointed it out.)
If you prefer to avoid requiring DNSSEC, you must verify the recipient
mail domain. In this case you have a much greater need for some kind of
support for server certificate selection (either SNI in TLS or perhaps a
new ESMTP TLS service extension), and you have to decide how to deal with
messages that have recipients at multiple different domains on the same MX
target server. This is all rather complicated and messy.
I'm trying to stay simple at this point, and only verify the recipient
MX server, not the recipient domains. That's already being widely done,
but (as I noted to Dave) without any clear specification for how to do
that in SMTP. However, as I go through RFC 6125, it pretty much does
seem to be covering everything I wanted (other than deprecating the
current common practice... *SIGH*)
<csg>