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.
