Re: [Trans] DNSSEC also needs CT

[Nico Williams <[e-mail]>]

On Tue, May 13, 2014 at 8:55 AM, Paul Wouters <[e-mail]> wrote:
> On Tue, 13 May 2014, Ben Laurie wrote:
>
> [DNSSEC CT]
>
>
>> Is it necessary to log anything other than keys? My base assumption was
>> no: if the keys are as expected, then all records signed by those keys
>> can be trusted. If someone wants to publish RRsets that are other than the
>> one the true domain owner wants to publish, they necessarily have
>> to inject a key they control, which becomes apparent from the logs.
>
>
> That would not allow us to detect coercion, that is a custom RRset signed
> to be used only for a targetted attack (by say, .com or the root)
>
> But I'm not sure how we _could_ detect that. Let's say they get an A
> record for www.victim.com that bypasses the NS RRset completely, that
> is, signed by the .com key. To notice this case, you would also need to log
> the change of zone cut.
>
> The other case is injection of a custom DS RRset. How would we tell the
> difference between the legitimate zone owner adding a DS record or an
> attacker/parent zone owner adding one? One defense would be to ignore
> any new DS record for a certain amount of time, but that runs into
> similar issues as pinning and TACK.

Yes, these are the issues that need resolving.  Hashing the RRset name
doesn't help either where the attack is based on inserting a different
RRset to misdirect the victim.  Nor is it possible to audit logs to
look for such attacks if there's no names.

Still, if the goal is to get the root(s) and TLDs to stay honest, and
since they don't need privacy, their logs can include unhashed names.
Further below in the hierarchy things get murky; I have no answers as
to those, but it seems likely that some (most! probably) zones below
the TLDs will absolutely want protection against zone enumeration.  Is
a modicum of privacy possible with CT for the PKI?

Nico
--