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

[Viktor Dukhovni]

On Thu, Aug 04, 2016 at 04:30:39PM -0700, Carl Byington wrote:

> Have you seen the mta-sts proposal:

Of course.

> 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
needless mistakes.

-- 
	Viktor.