[Cryptography] Certificates and PKI

Ben Laurie ben at links.org
Wed Dec 31 07:36:07 EST 2014

On 30 December 2014 at 04:18, Nico Williams <nico at cryptonector.com> wrote:
> 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..

I am still confused by this, but perhaps we are at cross purposes.

IMO, DT is about protecting delegation of keys to subdomains.

It seems some people are arguing that DT should also protect the
entire content of the zone.

It seems to me the latter is substantially harder, not least because
there certainly exist zones that are entirely dynamic and whose
contents vary rapidly over time.

That said, it does seem possible to me to _allow_ both schemes whilst
solving the obvious problems.

Let's call the first version (i.e. protection of keys) DTK and the
second (zones) DTZ.

1. Choice: make DTK mandatory, but include in the protected material a
flag which says whether the zone also does DTZ.

2. Spam: for both DTK and DTZ there's a spam problem (in DTK it is
that any domain can create subdomains essentially ad inifinitum).
Simple answer: allow logs to delegate to sublogs for subdomains.
Spammy domains get to run their own logs, or don't get protected:
their choice.

Monitoring DTZ, particularly for highly dynamic zones, strikes me as a
nightmare, btw. But it also seems to me that DTK is a more important

More information about the cryptography mailing list