On Mon, Feb 23, 2015 at 09:29:07PM +0000, Kevin San Diego wrote:

I'm trying to get to speed on the DANE implementation in Postfix, it appears to support only DANE certificate usage 2 (Trust anchor assertion) and 3 (Domain-issued certificate). Is there a particular reason why the public CA-signed certificate types wouldn't be supported as these are more likely (as of today, at least) to be installed on business and commercial platforms?

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

Extract from http://www.postfix.org/TLS_README.html#client_tls_dane:

"The Postfix SMTP client supports only certificate usages "2" and "3" (with "1" treated as though it were "3"). See tls_dane_trust_anchor_digest_enable for usage "2" usability considerations. Support for certificate usage "1" is an experiment, it may be withdrawn in the future. Server operators SHOULD NOT publish TLSA records with usage "1"."

The support for usage "1" simply pretends that the server operator published the right server certificate digest with the wrong usage and treats "1" as though it were "3".

Den 2015-02-24 00:23, skrev Kevin San Diego:

model. For the types of customers who already have to have public CA-cert validated SMTP communications (and associated accept on validation success/drop on validation failure policy set up with critical partners), the currently deployed field of MTAs which don't yet have SMTP client support for DANE at the won't be able to validate the TLS session if a DANE EE cert is used in lieu. Given that MX records point to a specific host or set of hosts on a per domain basis, I presently don't see how an organization could simultaneously support both traditional CA-cert validated TLS connections and TLSA (mode 2/3) validated TLS connections. Receiving SMTP servers can typically only be configured with a single server certificate per IP/port binding.

This was the bit that got me really confused as well. If I understand it correctly, you can still use mode 2/3 on a CA-signed certificate, you're just telling DANE-capable clients that they're not supposed to validate the certificate against the PKIX infrastructure. Non-DANE-capable clients will still do their normal thing when they see the certificate in their SSL/TLS sessions.

Regards Eivind Olsen

On Mon, Feb 23, 2015 at 11:23:07PM +0000, Kevin San Diego wrote:

The "no added security" bit makes some sense in the context of a compromised DNS environment, but this doesn't really address how an organization who currently utilizes public CA-certs is supposed to intermix their existing TLS SMTP client usage with self-signed/DNS-hosted certs in a TLSA record.

You can designate any CA as a DANE-TA(2) trust anchor. It need not be your own. Any record you might have published with usage PKIX-TA(0) can be published instead as DANE-TA(2), with the following conditions:

* The server certificate MUST include the TLSA base domain as one of the DNS subjectAltNames.

* Servers MUST send the trust-anchor certificate in their TLS ServerHello message along with the leaf certificate and any intermediates.

* Some Windows software (Schannel limitation?) reputedly cannot be configured to include the root CA in the server's TLS HELLO. In that case you need to use an intermediate CA as your DANE-TA(2) trust-anchor.

By stating usage mode 0 & 1 should be considered unusable, it seems to me that a company would need to choose between sticking with their current legacy opportunistic/site-specific forced TLS and moving to the DANE-EE model.

Not true. Public CA certificates work even better when you don't require the clients a-priori to trust the same CA you do business with.

Also, you can take any leaf certificate (or the underlying public key) issued by a public CA, and publish a DANE-EE(3) association for that.

The two models coexist seamlessly, and many existing DANE SMTP sites use certificates from a public CA.

For example:

spodhuis.org. IN MX 10 mx.spodhuis.org. _25._tcp.mx.spodhuis.org. IN TLSA 2 0 1 ea99063a0a3bda9727032cf82da238698b90ba729300703d3956943635f96488

Subject = CN=mx.spodhuis.org,O=GlobNIX Systems,C=US Issuer = CN=GlobNIX Certificate Authority 4,OU=Certification Authority,O=GlobNIX Systems,ST=Pennsylvania,C=US

On Sun, Mar 01, 2015 at 08:37:04PM +0100, Michael Str?der wrote:

Viktor Dukhovni wrote:

...

The two models coexist seamlessly, and many existing DANE SMTP sites use certificates from a public CA.

But you switch off X.509 validation if DANE is used.

Because server-signalled mandatory use of (some unspecified set of) public CA trust-anchors can only reduce interoperability and cannot contribute to security.

I'd like to see DNSSEC/DANE/TLSA as an *additional* mechanism but still requiring X.509 validation to be fully performed. With this multiple trust anchors would be effective which is IMO the real solution.

This is sloppy wishful thinking. You've not considered the security model carefully enough. It would sure be nice if using both gave you more security and reduced the chance of failure. Unfortunately, this would give you no additional security and would needlessly increase the chance of failure.

Since a compromise of DNS would allow the attacker to publish DANE-EE(3) records of his choice, the "requirement" to "harden" DANE with (some unspecified set of) public CAs is subject to a trivial DNS-only downgrade. So the security of this reduces to the security of DANE without the (unspecified) public CAs.

On the other hand, including the requirement to also use said CAs introduces significant opportunities for authentication to fail because the client does not have the server's chosen root CA in its trusted CA list, or the client has difficultly building the trust path for various reasons. There is no user to "click OK" in MTA-to-MTA SMTP when the Web PKI fails (as it does too frequently).