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

[[e-mail] (Martin Rex)]

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

  http://tools.ietf.org/html/rfc2818#section-3

and is described in a more elaborate fashion in rfc6125

  http://tools.ietf.org/html/rfc6125


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

  http://tools.ietf.org/html/rfc5246#page-56


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.


-Martin