Understanding SMTP DANE implementation options

Issuance Tech
3

Let's ping @ietf-dane here, who is an expert in this field.

Some terminology first: The different TLSA record types were given names (which I don't think were in RFC 6698, but are present in RFC 7671). The "type 2" is called "DANE-TA(2)", or just DANE-TA in short. I find this naming slightly easier to remember than numbering (particulary regarding their working, TA = trust anchor), so I'm going to use that terminology.

The third way you propose was briefly mentioned in old DANE posts: Please avoid "3 0 1" and "3 0 2" DANE TLSA records with LE certificates - #6 by ietf-dane

Yes, it is technically valid. I do recommend a full read of RFC 7671, in particular sections 5.2 and 5.3 mention some DANE-TA operational notes. RFC 7671: The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance. Basically, you have to send the root cert if you're using it in a DANE-TA type manner, unless you're including the entire cert in DANE via a 2-0-0 type record.

On the other hand, the RFC apparently does not recommend relying on 2-0-0 (as its difficult for implementations), but it does recommend including the DANE-TA relevant certs in DNS (in combination with another DANE-TA record (i.e. SPKI hash)) plus sending them over TLS.

In any case, you would likely want to primarily pin ISRG Root X1's SPKI hash in DANE, not the entire cert - there are already two versions of ISRG Root X1, and more may be created in the future. The SPKI hash is far more robust, also smaller.

Compatibility wise, I don't know if you throw off some implementations. Generally when you talk to mailservers, there are all kinds of weird TLS implementations that may not do the right thing and won't like your self-signed certs in chain. Remember that not all mailservers are going to use DANE validation. Those that don't use DANE usually don't enforce any PKIX validation, but in case they do, it always pays off to send a valid chain that can be PKIX validated with well-trusted root certs. The last thing you want is an unnecessary fallback to plain connections.

I personally like the DANE-EE concept most. It eliminates the PKIX validation worries altogether, pinning the leaf's public key instead. It might involve some effort to have good rollover schemes (current + next strategy is recommended), but the PKIX thing brings with it the entire drawbacks the current PKI has. It brings back issues like key usage incompatibilities, path validation issues, extension problems... I love DANE for the fact that it eliminates these things with a DANE-EE setup. Browsers nowadays are very good at path validation, but the email world is so much different, you never know what works.

Some "further reading" links that relate to this topic somewhat, just going to throw them into here for reference:

12 Likes