On Mon, Feb 23, 2015 at 11:23:07PM +0000, Kevin San Diego wrote:
The "no added security" bit makes some sense in the context of a compromised DNS environment, but this doesn't really address how an organization who currently utilizes public CA-certs is supposed to intermix their existing TLS SMTP client usage with self-signed/DNS-hosted certs in a TLSA record.
You can designate any CA as a DANE-TA(2) trust anchor. It need not be your own. Any record you might have published with usage PKIX-TA(0) can be published instead as DANE-TA(2), with the following conditions:
* The server certificate MUST include the TLSA base domain as one of the DNS subjectAltNames.
* Servers MUST send the trust-anchor certificate in their TLS ServerHello message along with the leaf certificate and any intermediates.
* Some Windows software (Schannel limitation?) reputedly cannot be configured to include the root CA in the server's TLS HELLO. In that case you need to use an intermediate CA as your DANE-TA(2) trust-anchor.
By stating usage mode 0 & 1 should be considered unusable, it seems to me that a company would need to choose between sticking with their current legacy opportunistic/site-specific forced TLS and moving to the DANE-EE model.
Not true. Public CA certificates work even better when you don't require the clients a-priori to trust the same CA you do business with.
Also, you can take any leaf certificate (or the underlying public key) issued by a public CA, and publish a DANE-EE(3) association for that.
The two models coexist seamlessly, and many existing DANE SMTP sites use certificates from a public CA.
For example:
spodhuis.org. IN MX 10 mx.spodhuis.org. _25._tcp.mx.spodhuis.org. IN TLSA 2 0 1 ea99063a0a3bda9727032cf82da238698b90ba729300703d3956943635f96488
Subject = CN=mx.spodhuis.org,O=GlobNIX Systems,C=US Issuer = CN=GlobNIX Certificate Authority 4,OU=Certification Authority,O=GlobNIX Systems,ST=Pennsylvania,C=US