[openssl-users] OpenSSL version 1.1.0 pre release 6 published
openssl-users at dukhovni.org
Thu Aug 4 23:48:07 UTC 2016
On Thu, Aug 04, 2016 at 04:30:39PM -0700, Carl Byington wrote:
> Have you seen the mta-sts proposal:
> But mta-sts starts with an unauthenticated dns TXT record.
Yes, this is but one of its compromises.
> 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.
You misunderstand the role of the DNS record in STS. It is a
cache-priming signal, it is not the actual policy, which is always
delivered via HTTPS.
You're also forgetting that RFC7672-compliant MTAs MUST NOT attempt
to retrieve TLSA records when the address records are insecure, so
"DANE=always" will almost never happen.
> 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.
Except that nobody will use it, when it lies in the same unsigned
zone as the host records.
> None of these MX, A, and TLSA records are signed. But mail senders
> *could* still enforce the constraints implied by that TLSA record.
But they MUST NOT look up the TLSA record except when it is (rarely)
a CNAME from a signed to an unsigned zone.
> 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.
I am not an avid fan of STS, but I am helping the authors to avoid
More information about the openssl-users