Subject: RE: namedroppers, continued

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 3 Dec 2002 08:21:22 -0800

> The fact that OCSP scales fine for revocation checking
> doesn't mean that
> you have a system that scales fine for the *TOTAL PROCESS*.

Stop blustering, you clearly did not know the difference between
a CRL and OCSP and certainly have no real world experience of
operating PKI on which to base your broad assertions.

> Also, there's the added issue that the DNS cuts down on
> traffic by way of
> caching.

The ATLAS cluster that runs the core DNS (.com, .net, .org) is
supporting six billion queries a day. The caching in the secondary
servers goes some way to reduce load but not as much as many think.

> Unfortunately, that's the LAST thing you want a CRL
> to be doing
> (in particular, negative caching is an extreme no-no).

No it is not. If you knew what a CRL is you would know that
they are issued on a periodic basis and that caching is
therefore exactly what Windows or any other sensible O/S
does with a CRL.

You appear to be confusing CRLs with OCSP. Try reading the OCSP
spec, I wrote the original section on caching responses.

		Phill

---

From: [email-masked]
Date: Wed, 04 Dec 2002 15:29:06 -0500

> operating PKI on which to base your broad assertions.

I said "total process".  The process failure described in the CERT
advisory didn't care if it was a CRL, OCSP, a X.509 certificate, or
a piece of paper scotch-taped to one end of a tin-cans-and-string link
that says "Don't use unless your name is Fred".

I admit I don't do any PKI per se.  What I *do* have is over 2 decades
of making a good living at cleaning up the mess when people misconfigure
things.  So I'm reading RFC2560 and see this in section 5:

    A denial of service vulnerability is evident with respect to a flood
   of queries. The production of a cryptographic signature significantly
   affects response generation cycle time, thereby exacerbating the
   situation. Unsigned error responses open up the protocol to another
   denial of service attack, where the attacker sends false error
   responses.

and I combine that with the research out of CAIDA I cited earlier that showed
98% of DNS queries to a root nameserver being broken, and my experience
tells me that This Is A Train Wreck Waiting To Happen.

The only mitigating factor here is that section 2.5 allows the precomputing
of a response and associated signature.

> spec, I wrote the original section on caching responses.

Hmm... I've checked RFC2560, and didn't find anything significant about caching
other than "beware HTTP proxies with broken caching" (or did you mean the
precomputation of responses in section 2.5)?  Also, is there a spec for a DNS
RR to supplement the serviceLocator extension of 2560 section 4.4.6?  That
would also help to minimize and distribute the load (as the OCSP RR could be
lumped in with the other DNS RR's for DNSSEC processing - handing back the OCSP
info in an "additional info" field then saves you another resource hit when an
OCSP query gets made.
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech