-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, 2016-08-04 at 22:33 +0000, Viktor Dukhovni wrote: > Such configurations will be rather rare, and offer minimal incremental > MITM protection. The code and documentation to support this use-case > and explain it to users are not worth the trouble. Have you seen the mta-sts proposal: https://tools.ietf.org/html/draft-brotman-mta-sts-00 That is a mechanism to allow mail receivers that (do not/can not) do DNSSEC, to publish some constraints on the tls keys on their mail servers. Senders can reject connections that violate those constraints. But mta-sts starts with an unauthenticated dns TXT record. If that proposal is worth anything, it indicates there is some use for a mechanism to allow publishing unauthenticated data in dns to be used by mail senders to constrain the acceptable tls keys. I think it is better to publish an unauthenticated TLSA record, rather than to publish an unauthenticated TXT record that then leads to an https url which then delivers the tls key constraints. ; example.com zone is unsigned example.com. IN MX 0 smtp.example.com. smtp.example.com. IN A 192.0.2.1 _25._tcp.smtp.example.com. IN TLSA 3 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 None of these MX, A, and TLSA records are signed. But mail senders *could* still enforce the constraints implied by that TLSA record. Compared to mta-sts, this is easier for mail senders (a single TLSA record, rather than a TXT record and an entire https infrastructure with its own tls keys and pki certificates). It is also easier for mail receivers, since it is not much code to relax the "must be dnssec signed" constraint in the existing DANE code. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlej0AgACgkQL6j7milTFsG7JwCfQ3FkX2MOdr/pMBneFImyoI/R PXEAnjj6t6HF//susl7XmFZXipsgxT8q =H4FQ -----END PGP SIGNATURE-----
