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

[[e-mail] (Martin Rex)]

Viktor Dukhovni wrote:
> Martin Rex wrote:
>> Viktor Dukhovni wrote:
>>> 
>>> 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.

I'm sorry for having been so unclear.  I wasn't objecting to
the "name checks" part here, only to the "both ... and key usage".


> 
> 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).

This is about TLS implementations.  Keep in mind that the server does
not even need to know about DANE at all -- anyhow the server WILL
be acting on the KeyUsage in his very own certificate and drive
the choice of cipher suites based on the KeyUsage requirements
from the quoted part of the TLS spec:

>
>> DANE does NOT invalidate the key Usage checks and requirements that are
>> normally part of TLS itself and described here:
>> 
>>   http://tools.ietf.org/html/rfc5246#page-56
> 
> 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.

Nope.

Defective implementations excepted, the TLS protocol engine will
look at the KeyUsage attribute of the Server certificate and check
the cipher suite selection for compatibility -- and the application
call will NOT have a say in this.


> 
> 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.

You should not confuse EKU checks on the leaf certificate with
KeyUsage checks on the leaf certificate.  EKU checks on the leaf
certificate are extremely application specific, and simply undefined
for the majority of application protocols.
TLS itself (rfc2246,rfc4346,rfc5246) is entirely ignorant of EKU,
and so is HTTP-over-TLS (rfc2818).


Browser vendors together with CAs have defined semantics for EKUs
that browsers (but not necessarily generic TLS libs and programmatic
HTTP clients) will typically check, such as the two
id-kp-serverAuth and id-kp-clientAuth from PKIX(rfc5280)

  http://tools.ietf.org/html/rfc5280#page-45

Curiously, these EKUs are primarily a PKIX obsession, TLS just doesn't care.
And PKIX has defined these two serverAuth and clientAuth purposes with
an extremely narrow semantics:  "TLS WWW server authentication"
and "TLS WWW client authentication", which means that these would
explicitly *NOT* apply to something like "TLS SMTP authentication"
or "TLS SIP authentication", "TLS POP/IMAP authentication",
"TLS XMPP authentication", etc.


Whether a TLS server or TLS client will act on the expiration of an
X.509 server certificate is also implementation dependent, and similarly,
the application caller (that is using DANE for establishing trust),
may not get a say in that.  That is particularly true for the server-side
which may not necessarily see/use any DANE code.


I would really appreciate if you would refrain from suggesting to
create and use bogus X.509 certificates with DANE, _including_ CU=3.
DANE is an alternative means to establish trust, and for
CU=3 it additionally shortcuts/omits the name checks.  But not more.
If you desperately want naked keys, join Paul Wouters in his effort
to get that working with TLS.




-Martin