[openssl-users] OpenSSL version 1.1.0 pre release 6 published

Carl Byington carl at five-ten-sg.com
Thu Aug 4 23:30:39 UTC 2016

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:


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
_25._tcp.smtp.example.com. IN TLSA 3 1 1

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.

Version: GnuPG v2.0.14 (GNU/Linux)


More information about the openssl-users mailing list