[Cryptography] Certificates and PKI

Nico Williams nico at cryptonector.com
Mon Dec 29 23:18:10 EST 2014


On Sun, Dec 28, 2014 at 03:05:00PM +0000, Viktor Dukhovni wrote:
> On Sat, Dec 27, 2014 at 12:22:21PM -0500, Paul Wouters wrote:
> > >CT for parent domains serving entries in what should be a child
> > >domain is doable I think.
> > 
> > As someone told me offline, qname minimalization actually solves this
> > problem.
> 
> This had occured to me, but there are some issues:
> 
>     * With "_<port>._<proto>.mxhost.example.com" one might
>       now need to make 5 queries instead of 3, unless there
>       is way to "tune" minimization.  I am concerned about the
>       impact on latency.

It doesn't seem likely that there would be a zone cut between
mxhost.example.com and _<proto>.mxhost.example.com, or between
_<proto>.mxhost.example.com and _<port>._<proto>.mxhost.example.com.

Now, the resolver might not be in a good position to know where to stop
looking for zone cuts, but the application might be.

Anyways, 5 would be the max; 4 would be the likely max, so just one more
query (still, 33% more, unless we know where to stop QName
minimization).

Also, we could have zones that must always cut...  It's might be too
late to go there, but it'd have been convenient for QName minization.

As to latency, it can be traded off for load by parallelizing queries,
though that's probably scarier than the extra latency.

Another problem is that this means that stapling DANE is not enough:
the client will have to check for zone cuts that don't appear in the
stapled data.  Again, some heuristics about where we can expect no zone
cuts will help; in the majority of cases that should suffice.

>     * This still might not address denial of existence "spam".

OK, so CT for DNSSEC has to log not just delegations signed (or made at
all, signed or not) by the parent, but also all would-be
out-of-bailiwick RRs served by the parent, and related NSEC3 RRs as
well.

Identifying requirements for CT for DNSSEC is a good thing..

Incidentally, if the WebPKI were strictly hierarchical, then we could
say the same exact thing about CT for PKIX, no?  It's good to have
problems that the WebPKI doesn't have because the problems it has are so
much bigger...

Nico
-- 


More information about the cryptography mailing list