Re: [TLS] Certificate validation can of worms

[Nico Williams <[e-mail]>]

On Fri, Apr 04, 2014 at 10:15:39PM -0700, Watson Ladd wrote:
> On Fri, Apr 4, 2014 at 9:17 PM, Nico Williams <[e-mail]> wrote:
> > Let's take #2 first.  Here's two entrants:
> >
> > - x.509 naming is impossibly difficult to deal with (see RFC4514);
> >
> > - stapled OCSP is how it should have been from day one -- CRLs add a ton of
> > complexity
> 
> You are ignoring the reason we have CRLs in the first place: stapled
> OCSP assumes all devices are globally connected and so can get OCSP.

This is the off-line infrastructure argument.

If you have the same freshness policy for CRLs and [stapled] OCSP then
you have the same on-line/off-line trade-off but with the on-line
infrastructure access burden moved from the RP's shoulders to the
presenter's.

In terms of mechanics, stapled OCSP Response validation is simpler than
CRL checking, and its operational characteristics are *much* better
(just ask the DoD).

> Furthermore, neither naming nor OCSP/CRLs were involved in this
> research, although the complexity may have lead to corners being cut
> in the rest of the code.

What TLS/PKIX libraries have historically implemented naming constraints
correctly, or at all?

Naming constraint usage and enforcement are critical for PKI, so that a
CA compromise in -say- the Netherlands doesn't affect anyone outside its
purview.

With DNS the naming constraints were always there, so DNSSEC gets them
for free.

OTOH, DNS is lousy for representing some types of names -- IP addresses,
for example.  But for the things we desperately need strong security
for, namely server/service names, DNS is perfect.

DNS is perfect for host/domain naming because it's what won for
host/domain naming, so it's what we all use for host/domain naming.
x.400/500-style naming was a horrible, useless mess from day one, and
we're still stuck with x.500-style naming for TLS server certs, with
kludgy conventions layered on top.

The research you linked didn't deal with naming.  That doesn't mean
naming isn't a problem for PKI.  You asked, I answered :)

> > Back to #1:  DNSSEC is a PKI, but with better naming and fewer root CAs.
> > We're going to need CT for DNSSEC.
> 
> Well, you're assuming that all implementations will agree on DNSSEC
> validity. Even if they do, DANE connects to the X509 ecosystem. This

I'm not sure what you mean by "agree on DNSSEC validity".  If you mean
"agree to place high value on DNSSEC", no, I'm not assuming that.

Still, assuming that [we have any significant reliance on DNSSEC (and
why wouldn't we for at least some things)] for Internet security,
doesn't it stand to reason that, being a PKI, DNSSEC will need to
address transparency?

Even if we don't replace the TLS server PKI with DANE... generic PKI
problems -as opposed to x.509/PKIX-specific ones- will surely apply to
DNSSEC.

> raises the problem of validating the parts between the TLS connection
> and the link to DANE.

Hmm?  What are the problems here?  DANE specifies this "link" in detail.

And if DANE "certificate usage 3" cuts out the PKIX world almost
completely.

> >> 3: This focused on server authentication. How does client authentication
> >> fare?
> >
> > Very differently.  For user authentication I think something more like
> > Persona (still PK, but not Internet-scale PKI) is better.  We really need a
> > standard account & device enrollment protocol to make user PK work well --
> > then we can land wherever on the PKI..web-of-trust..ad-hoc spectrum the
> > market likes best.
> 
> Enrollment and accounts are secondary to making sure everyone agrees
> on what a valid certificate looks like. If you don't have that, you

Certificate validation is a sine qua non for PKI, no doubt, at least for
_servers_/_services_.  For users it's different since you might just do
TOFU enrollment and only match on public keys (or the public key of a
user's private "root CA").

Therefore, and considering the extremely low penetration of PKI for user
authentication in TLS, I think certificate validation is not really all
that relevant to the user authentication side of things.  Depending on
how one chooses to use PK (not necessarily I) for user authentication,
certificate validation can be a separable [non-]problem.

One could publish user name/public key pairings in the DNS[SEC] and
enroll user accounts in domains which then act as CAs/IdPs, in which
case "certificate validation" becomes relevant again.  But in any case,
account/device enrollment is a big deal if you want to use PK for user
authentication in a scalable and reusable way.

> can't trust the results of authentication. This research analyzed

Why do you assume that PKI is the only way to use PK?

> server certificates only. It didn't have user certificates to play
> with. Furthermore, if X509 implementors  got this wrong, how do we get
> it right?

By simplifying.  I'm not saying DNS is simple, but the ugly parts of it
are not really relevant to the cryptographic security side of things,
while the ugly parts of PKIX are (see above).  In particular DNS naming
is trivial, and so are name constraint expression and checking.

Nico
--