DANE presentation (in German)

[Viktor Dukhovni]

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

-- 
	
	Viktor.