Setting up Dane again from start

[Viktor Dukhovni]

On Wed, Feb 11, 2015 at 12:59:01PM +0100, Frank Fiene wrote:

> This should work for pop3s and imaps, too, shouldn?t it?
> What is about pop3 and imap with TLS, the same?

For a shared key for multiple services that use distinct protocols:

	_dane.mail.example.com.     IN TLSA 3 1 1 <sha256 SPKI digest>
	_25._tcp.mail.example.com.  IN CNAME _dane.mail.example.com.
	_110._tcp.mail.example.com. IN CNAME _dane.mail.example.com.
	_143._tcp.mail.example.com. IN CNAME _dane.mail.example.com.
	_587._tcp.mail.example.com. IN CNAME _dane.mail.example.com.
	_993._tcp.mail.example.com. IN CNAME _dane.mail.example.com.

This only makes sense if you need the certificate to be from a
public CA trusted by some SMTP/IMAP/POP clients.  For port 25, you
should just go with a distinct self-signed key.  Not sharing keys
avoids simultaneously breaking all the services that share that key
when a mistake is made during key rotation.

To generate the "3 1 1" SPKI digest:

    printf '_dane.%s. IN TLSA 3 1 1 %s\n' \
        mail.example.com \
        $(openssl x509 -in cert.pem -noout -pubkey |
            openssl pkey -pubin -outform DER |
            openssl dgst -sha256 -binary |
            hexdump -ve '/1 "%02x"')

* Never make the mistake of using a certificate digest with a "3 1 1"
  TLSA record or an SPKI (i.e. SubjectPublicKeyInfo or, in other words,
  the public key algorithm id, parameters and key bits) digest with
  a "3 0 1" TLSA record.

* Never make the mistake of installing a new key or certificate without
  following the TLSA record update process described in:

    http://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1
    http://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.4

-- 
	Viktor.