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: > > 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. 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. -- Viktor. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
