Subject: [dane] Postfix 2.11.0-RC2 available with feature-complete DANE support

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 10 Jan 2014 00:17:26 +0000

Postfix 2.11.0 is now in code-freeze.  With 2.11.0-RC2 the DANE
support is feature complete, and matches the DANE SMTP draft.

The official 2.11.0 release will happen in the next couple of weeks.
Test feedback welcome.

    http://www.postfix.org/TLS_README.html#client_tls_dane
    http://www.postfix.org/TLS_README.html#client_tls_policy

While I am busy with IETF drafts, some brave souls have volunteered
to contribute a more consolidated DANE_README tutorial.  I'll post
a link here when/if all goes well on that front.  Currently the
DANE related information is scattered over a few documents.

Minimal client configuration:

    Note: A DNSSEC validating resolver MUST be present on the
    LOOPBACK interface and MUST be the only resolver listed in
    /etc/resolv.conf.  Postfix delegates DNSSEC processing to the
    system's caching resolver.  A local resolver is in any case a
    good idea for an MTA that handles non-trivial mail volumes.

    /etc/resolv.conf:
	nameserver 127.0.0.1

    main.cf:
	smtp_host_lookup = dns
	smtp_dns_support_level = dnssec
	smtp_tls_security_level = dane
	ignore_mx_lookup_error = no

Recommended Server DNS configuration:

	example.com. IN MX 0 mx.example.com.

    Publish one of the two TLSA record forms below, the remaining
    22 combinations have little to recommend them:

	; Per-service EE SPKI TLSA RR:
	;
	_25._tcp.mx.example.com. IN TLSA 3 1 1 {EE SPKI SHA2-256 digest}

	or

	; Domain-wide TA CERT TLSA RR, aliased from each service:
	;
	_25._tcp.mx.example.com. IN CNAME 2.1.1._tlsa.example.com.
	2.1.1._tlsa.example.com. IN TLSA 2 0 1 {TA CERT SHA2-256 digest}

    In the second case the domain-issued TA certificate MUST be
    included in the server chain file:

	# cd /etc/postfix
	# cat ee-cert.pem intermediate.pem ... root-ta.pem > chain.pem
	# postconf -e 'smtpd_tls_security_level = may'
	# postconf -e 'smtpd_tls_cert_file = ${config_directory}/chain.pem'
	# postconf -e 'smtpd_tls_key_file = ${config_directory}/ee-key.pem'

    and the ee-cert MUST have at least one of "mx.example.com" or
    "example.com" as a DNS subjectAltName or subject commonName.

    Avoid wildcard certs, they may allow MITM attackers to redirect
    connections to the wrong hosts.

See http://www.postfix.org/FORWARD_SECRECY_README.html for additional
server TLS tuning.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 10 Jan 2014 00:25:33 +0000

On Fri, Jan 10, 2014 at 12:17:26AM +0000, Viktor Dukhovni wrote:

> 	2.1.1._tlsa.example.com. IN TLSA 2 0 1 {TA CERT SHA2-256 digest}

The "2.1.1" should have been a  "2.0.1":

 	; Domain-wide TA CERT TLSA RR, aliased from each service:
 	;
 	_25._tcp.mx.example.com. IN CNAME 2.0.1._tlsa.example.com.
 	2.0.1._tlsa.example.com. IN TLSA 2 0 1 {TA CERT SHA2-256 digest}

The reason for "2 0 1" is that with "2 0 1" records Postfix honours
various properties in the TA certificate.  For example, path length
constraints, ...  With "2 1 1", the public key is trusted directly,
and the rest of the TA certificate is ignored.

So I had the right TLSA parameters, but a misleading associated
domain name.

-- 
	Viktor.