On 1/10/16 9:27 PM, John Levine wrote:
In the EAI case, it turns out that there is no plausible
"downgrade" path corresponding to "give up and send clear text"
in historic STARTTLS so "required extension" is the only game in
town and messages either go through or they don't. However,
the strongest critique of EAI -- IMO an entirely valid one at
least until the protocol extensions are widely deployed -- is
that it basically divides the email world into two communities
who can't talk with each other. You risk the same type of
Only sort of. In this case, the downgrade path is obvious, you
ignore the TLS flag and send the message along.
That's the opposite of the goal here. SMTP makes tries to delivery
messages, even if that results in a downgrade in security. The goal here
is to fail the transmission of REQUIRETLS tagged messages that can't be
sent in accordance with the originator's security requirements.
Upon slightly more reflection, I think I see why this isn't likely to
be useful. Any MTA that understands the REQUIRETLS flag will almost
certainly do opportunistic TLS anyway, so you haven't gained much
there. In the absence of DNSSEC, you still have the attack where a
bad guy sends you a fake MX, so you deliver 100% securely to the wrong
place, so you have yet another steel door on a cardboard box.
The goal here is to not send messages to MTAs that don't do TLS (and
But you make a good point about the fake MX problem: if you're concerned
about DNS attacks, you need to make sure that the recipient domain, and
not just the domain of the MX server, is DNSSEC protected. That's an
oversight in the specification I will correct.
If you do have DNSSEC, you can use RFC 7672 TLSA to be sure you're
delivering to the right place. So what does this buy you in practice?
It buys the originator of the message the ability to specify that TLSA
actually be used. As long as it's opportunistic, the message might be
sent in the clear, and TLSA is then moot.
Speaking of RFC 7672, see its section 1.3 which looks to me like it
contemplates an approach like this and describes its problems.
This directly addresses the STARTTLS Downgrade Attack in 1.3.1 and does
not require sender policy as described in 1.3.3. The problem of too many
certificate authorities in 1.3.4 is addressed by the DANE option. The
Insecure Server Name Without DNSSEC in 1.3.2 will be addressed when I
correct the above oversight.
ietf-smtp mailing list