Re: [dane] I-D Action: draft-ietf-dane-srv-04.txt

Viktor Dukhovni <> Wed, 12 February 2014 23:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ADD0D1A0022 for <>; Wed, 12 Feb 2014 15:28:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J2b7OjQJL_tk for <>; Wed, 12 Feb 2014 15:28:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 543111A002A for <>; Wed, 12 Feb 2014 15:28:16 -0800 (PST)
Received: by (Postfix, from userid 1034) id 9F5C12AB245; Wed, 12 Feb 2014 23:28:14 +0000 (UTC)
Date: Wed, 12 Feb 2014 23:28:14 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-04.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Feb 2014 23:28:19 -0000

On Wed, Feb 12, 2014 at 11:54:56PM +0100, Martin Rex wrote:

> >> Thank you for the feedback, Viktor.  These comments make sense to me.
> >> We'll try to get an update out before the cutoff to address them.
> > 
> > Thanks.  You could mention that both name checks and key usage are
> > effectively handled by the TLSA record for DANE-EE(3).
> I'm sorry, but this simply isn't true today, I do not believe that
> this is (nor should be) the intention of DANE, and I'm strongly
> opposed to changing that part of the implementations.

No name checks for CU-3 IIRC was discussed and agreed many months ago.

There is no "true today" for DANE, as there are in effect no "real"
DANE implementations aside from the one in Postfix (I've looked at
some experimental implementations, but they are all incomplete and
often insecure).

The requirement to not do name checks, EKU checks, date checks for
DANE is satisfied by the Postfix DANE implementation, and will be
satisfied by the OpenSSL implementation on which I'm collaborating
with one of the OpenSSL developers.

This requirement makes it possible to use a single certificate to
work with multiple TLSA base domains, substantially simplifying
virtual hosting.  (See the ops draft).  Thus it substantially
enhances the usability of DANE.

The effective chain of trust for a server public key with DANE CU-3
is the chain of DNSKEY and DS RRsets starting at the relevant DNSSEC
trust anchor.  There are no X.509v3 trusted parties with CU-3 whose
signature on a leaf certificate validates the certificate content.
In fact with "3 1 1" the holder of the public key is free to replace
the certificate with any certificate for the same public key,
setting new dates, new names, ...

> DANE it self is about an alternative means to establish (a chain of) trust
> to a peer entity, and the usage type 3 only overrides the server endpoint
> identification that was originally described in rfc2818 section 3.1

I thought DANE stood for "DNS-Based Authentication of Named Entities".
With CU-3 TLSA RRset binds a port/protocol at a named transport
endpoint (the name is the TLSA base domain) to the corresponding
public key or public-key certificate.

Since this binding already takes care of naming the entity (with
more specificity than one typically finds in X.509v3 certificates),
establishes the validity interval of the binding, and via the
DNS RR type (TLSA, SMIMEA, ...) implies a suitable usage, there
is nothing left for the (untrusted content beside the public
key with "3 1 X"!) certificate to specify.

Since the certificate is redundant, and ignoring is a major
improvement in the deployability of DANE, the only reasonable thing
to do is to ignore the CU-3 certificate content (except to the
extent required to compare it with the TLSA association data).

> DANE does NOT invalidate the key Usage checks and requirements that are
> normally part of TLS itself and described here:

Those other documents assume that the content of the certificate
is from a trusted authority.  This is true for CU in {0, 1, 2},
but false for CU=3.

If the server operator wants to cease using a CU=3 certificate, he
should publish new TLSA RRs and deploy a new certificate (with due
care about key roll-over, see the ops draft).  There is no need for
clients to enforce expiration when the server is far better positioned
to do so.

> There are a number of TLS protocol stacks that will check the
> Key Usage of X.509 certificates that are conveyed through TLS certificate
> handshake messages, independent of how the application caller decides
> to perform server endpoint identification and how the application caller
> determines its trust.

This is not relevant, they don't do DANE.

When they do DANE, which needs to be supported by the TLS library,
as application-only DANE support is actually rather difficult, they
will handle CU=3 appropriately.

The Postfix DANE implementation uses very low-level OpenSSL features,
and essentially bypasses or duplicates or fools the existing
OpenSSL verification code to accept DANE chains.

Implementations will have to change to properly support DANE.
Expecting application to correctly implement DANE support would
lead to precisely the problems I've seen with every single current
experimental DANE verifier I've seen.  They're all flawed.