Re: [dane] I-D Action: draft-ietf-dane-srv-04.txt (Martin Rex) Wed, 12 February 2014 22:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ED6451A0002 for <>; Wed, 12 Feb 2014 14:55:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dEnFdr0iU2MB for <>; Wed, 12 Feb 2014 14:54:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 73E091A0024 for <>; Wed, 12 Feb 2014 14:54:58 -0800 (PST)
Received: from by (26) with ESMTP id s1CMsujN006489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <>; Wed, 12 Feb 2014 23:54:56 +0100 (MET)
In-Reply-To: <>
Date: Wed, 12 Feb 2014 23:54:56 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
From: (Martin Rex)
X-SAP: out
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 22:55:05 -0000

Viktor Dukhovni wrote:
> Matt Miller wrote:
>>> DANE-EE(3) CU records need to have meaningful semantics for the 
>>> publisher.  For example for a publisher to use the same
>>> certificate for many SRV hosts or without worrying about using a
>>> matching name, the use of non-use of name checks must be specified
>>> precisely.
>>> Therefore I would suggest that the "MAY be ignored" in the second 
>>> paragraph of section 5, should be changed to "MUST be ignored". 
>>> Otherwise, the published TLSA records have unknown semantics.
>> 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.

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

and is described in a more elaborate fashion in rfc6125

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

There are a number of TLS protocol stacks that will check the
KeyUsage 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.