On Fri, Jan 30, 2015 at 11:07:17AM +0300, Andreas Tauscher wrote:

Is there a recording or are slides available from Viktor's talk?

My slides don't make for good prose, they are rather terse (as slides ought to be).

Or is somewhere an overview available brining light in the 25 different types of TLSA records?

That 24, but only 12 are applicable to SMTP because certificate usages PKIX-TA(0) and PKIX-EE(1) are unsupported.

Also, records with full certificates and full keys are not recommended so that brings us down to 8.

In addition, SHA2-256 is plenty strong (256 bits of 2nd-preimage resistance). Use of SHA2-512 with TLSA for SMTP is just crypto-porn. So this brings us down to 4.

When the certificate usage is DANE-EE(3), only the public key in any certificate is relevant, the hostname, expiration, and essentially everything else in the certificate are of no consequence. Matching just the key makes it possible to renew public CA certificates without TLSA record updates, and is compatible with (future) use of RFC 7250 raw public keys in TLS handshakes.

* Therefore, any DANE-EE(3) TLSA record is ideally a "3 1 1" record:

; smtp.example.com. IN TLSA DANE-EE SPKI SHA2-256 <public key digest> ; smtp.example.com. IN TLSA 3 1 1 03ba204e50d126e4674c005e04d82e84c21366780af1f43bd54a37816b6ab340

When the certificate usage is DANE-TA(2), the full CA certificate is more pertinent, as some of its components (path length, name constraints, ...) may be important.

* So with DANE-TA(2), one would typically go with a selector of Cert(0), giving best-practice records of the form:

; Centralize TLSA RRs of subject servers at single enterprise ; trust-anchor TLSA record: ; trust-achor._dane.example.com. IN TLSA 2 0 1 03ba204e50d126e4674c005e04d82e84c21366780af1f43bd54a37816b6ab340 ; mx1.example.com. IN CNAME trust-achor._dane.example.com. mx2.example.com. IN CNAME trust-achor._dane.example.com. ...

It is critical to include the full TA certificate in each server's TLS chain file configuration.

I've received reports that it is difficult to convince Microsoft Exchange servers to include "root" (self-signed) certificates in their TLS handshake wire chain. For these, the TLSA RR may need to specify the digest of an intermediate CA that the servers are able to send.

See

https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-5.1 https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-5.2 https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-6 https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1 https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.4

https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13#section-3.1.1 https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13#section-3.1.2 https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13#section-3.1.3