Paul Hoffman (thanks) points out that there may be prior consensus
with respect to the applicability of DANE TLSA to "discovery" of
TLS enabled services.
I was not party to the original discussion of this topic, my
apologies if I am about to repeat previously discussed ideas.
The SMTP draft defines an opportunistically secure protocol. For
inter-domain email on Internet scale, no domain has prior knowledge
of the set of peer domains (more specifically their MX hosts) that
support TLS.
Today's MTA employ TLS opportunistically, based on the offer of the
"STARTTLS" SMTP extension in the SMTP server's EHLO response. This
offers no protection against MITM attacks (or even transient errors,
as many SMTP clients will retry in cleartext after TLS transmission
fails).
The DANE SMTP draft aims to provide a downgrade-resistant protocol
by which SMTP clients can determine (discover if you will) that a
given SMTP server support TLS and expects DANE SMTP clients to
avoid using cleartext delivery with the server. The associated
TLSA records are used to authenticate the server to mitigate MITM
attacks that terminate TLS (rather simply suppress it).
If determining whether TLS support is required is incompatible with
DANE, I see no purpose for the SMTP draft. We already unauthenticated
opportunistic TLS for SMTP (STARTTLS) which is vulnerable to various
downgrade attacks. Without a secure signal to do TLS, the downgrade
attacks remain, and opportunistic TLS does not benefit from DANE.
So I hope the group can reach consensus that it is OK to use TLSA
records to discover a requirement for TLS. This approach is not
new with the SMTP draft, it dates back to the original SRV draft
from Tony Finch, and is still stated in the revived version of that
document.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
