-----BEGIN PGP SIGNED MESSAGE-----
On Tue, 26 Jul 2016 22:07:59 -0700, mrludo001 wrote:
> Thanks for the input. Section 2 of draft-ietf-uta-mta-sts-01
> DANE vs MTA-STS .
Yes, the quote is from that section. The point is that if you start with
an insecure DNS lookup, you cannot really enforce *mandatory* tls
example.com. MX 10 mail.example.com.
mail.example.com. A 192.168.1.1
If you do want to use an insecure DNS lookup to close some of the holes
in opportunistic tls, I think it is better to use:
_25._tcp.mail.example.com. TLSA 3 0 1 ....
_mta_sts.example.com TXT "v=STSv1; id=randomstr; ...."
Both of those records (TLSA and TXT) are fetched via an insecure DNS
lookup but the mta_sts TXT record also requires an auxillary HTTPS
server. You could (via local policy) simply extend DANE to obey the
constraints implied by that TLSA record, even though example.com is not
secured with DNSSEC.
That option is in my sendmail patch. This allows folks that (for
whatever reason) don't secure their zones with DNSSEC, to at least
publish an indication of the expected tls usage of their incoming mail
servers. And when they do upgrade to DNSSEC, they get the full DANE
With respect to mail, we already publish public cryptographic keys for
dkim via insecure DNS TXT records, and those keys can be used by mail
receivers. We can also publish public cryptographic tls keys via
(hopefully secure) DNS TLSA records, and those keys can be used by mail
senders to validate the connection to the mail receiver.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
-----END PGP SIGNATURE-----