Re: [TLS] Cert Enumeration and Key Assurance With DNSSEC

[Nicolas Williams <[e-mail]>]

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