Sorry... I'm still missing something...
--On Monday, January 11, 2016 16:29 +0000 John Levine
I meant obvious as in what people will do as opposed to what
matches the semantics of some threat model. If you have an
EAI message with a UTF-8 address, handing that to a non-EAI
mail server is unlikely to do anything useful. If you have a
tls-only message, handing it to a non-tls-only mail server is
likely to get it delivered, albeit without the TLS coverage
and perhaps (lacking DNSSEC) to the wrong place but that could
Ok. I get that part. And there is less different from the EAI
case than you presume. In the EAI case, what the originator
does upon discovering the message couldn't be delivered is to
try to find an all-ASCII address (and/or pick up the virtual
telephone). In this case, it tries to find a non-TLD-only
server (which may be hard if, as other messages have suggested,
all servers for a given destination have exactly the same
service configuration). Perhaps the easiest way to do that is
to find a different/better address... and that is almost exactly
the same as the EAI case. Where the two cases actually differ
is that all that needs to be done for the TLS case is to find a
server that will let the message through; for EAI, the
originator is likely (but not always) to have to some serious
alterations to message, or at least message header, content.
Unless I've missed something, 7672 doesn't help.
With RFC 7672 the MX and A/AAAA records are signed so you know
you have the right IP address. There's also a signed TLSA
record for the MX, e.g.
_25._tcp.mailserver.example.com IN TLSA blah
If the mail server you contact doesn't present a certificate
that matches the TLSA record, you know you have problems.
By my reading of 7672, if a domain goes to the trouble of
publishing the signed MX, A, and TLSA, you should believe it
and decline to deliver mail if you don't get the right cert.
This is basically the reverse side of Jim's proposal, the
recipient asserts that it does TLS rather than the sender
asserting that it wants TLS.
Ok. So you are a sender. You have an IP address, say 184.108.40.206,
that you have gotten from the DNS after making an MX query. It
is signed, certified, and gold-plated. You open a TCP
connection to port 25 on that address and send the packets out.
I'm a nasty and motivated attacker who has compromised part of
either your LAN or the WAN (before the LAN of the delivery
server) your connection has to traverse, and I've compromised it
thoroughly -- not only can I eavesdrop, but I "own" the routers.
I can take the packets you are sending to 220.127.116.11 and divert
them anywhere I like. If you want a cert bound to that address,
I can make one up and send it to you.
Now, one could further harden that by making DNS records that
identified, e.g., the CA that would be required to sign any
certs or records from the address. My skimming of 7672 suggests
it doesn't go that far. Other DANE pieces sort of try.
Experience with the variable quality of coordination and
cooperation between mail server operators and DNS operators in
organizations large enough to have them be separate functions
suggests that level of linkage will lead to a lot of false
negatives and unnecessary rejections, but maybe that is a
We have a mechanism, IPSEC, for protecting against those types
of attack. I'm pessimistic about our really being able to
emulate its functionality at the applications layer.
On the other hand, as I understood you to point out earlier, if
the recipient asserts it can accept TLS in a way that makes both
the assertion and the addresses and credentials verifiable, then
the value added by a "if you refuse to do this, reject the
message" extension is fairly small.
ietf-smtp mailing list