On Fri, Oct 01, 2010 at 11:29:35AM -0400, Phillip Hallam-Baker wrote: > What I object to is the approach being taken which is to use DNSSEC to > replace PKIX certificate validation entirely. > > Now the proponents are trying to downplay this by saying that 'all' they are > doing is to tell people to 'ignore' PKIX validation. But that approach > really offends my sense of layering.
I think the layering argument is the strongest argument here. To be sure, the KEYASSURE approach offends my sense of layering too, but not in the same way: IMO this is a change to how certificate validation is done, therefore an update to RFC5280, ISTM, is required. What I'd like to see is for the DNSSEC approach to certificate validation be considered as a change to TLS and/or PKIX. That is: - RFC5280 should be updated to describe DNSSEC-based validation of certificates. There are a number of security considerations here that must be considered in the context of PKIX. For example: can a DNSSEC- validated certificate be a CA certificate, and if so, what might its scope be? Are there implied naming constraints? Or: when is it OK to try one (traditional PKIX valdiation) or the other (DNSSEC), and when is it OK to fallback on the other? (Perhaps this is what you meant by giving the attacker two infrastructures to attack. If the validation policy of the rp can be forced to fallback on a less preferred mechanism via a DoS attack, then the attacker has something to work with.) I've _not_ reviewed the KEYASSURE documents, so I'm not sure if these security considerations are being addressed/documented. - TLS implementations should offer applications whatever choices the update to RFC5280 requires, if any. Choices such as: validation policy choices (trad-PKIX-only, DNSSEC-only, trad-PKIX-and-DNSSEC, DNSSEC-fallback-on-trad-PKIX-only-if-NXDOMAIN-is-secured, DNSSEC- fallback-on-trad-PKIX). TLS doesn't have abstract interfaces, but some text regarding this in an update to TLS 1.2 seems appropriate to me. Alternatively, such text could belong in the RFC5280 update, but even then, I think TLS implementors specifically need to be made aware of this new certificate validation option and its security considerations. The main security consideration here is, I think, about when to try one, the other, or both of traditional PKIX or DNSSEC certificate validation. Nico -- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
