Re: [Trans] [dane] CT for DNSSEC

[Wei Chuang <[e-mail]>]

Thanks very much Viktor that explanation of NSEC(3).  Just one follow up
idea:

On Mon, Mar 20, 2017 at 6:00 PM, Viktor Dukhovni <[e-mail]>
wrote:

>
> > On Mar 20, 2017, at 6:43 PM, Wei Chuang <[e-mail]> wrote:
> >
> >>> No, this is because the parent can spoof any data for the child.
> >>> It is unrelated to DNSSEC.
> >>
> >> With qname minimization, the parent will first need to deny an NS
> >> RRset for the child, and those DOE records are better candidates
> >> for logging than routine non-NS queries.
> >
> > Can you expand on how the the DOE record (which I assumes means
> > denial-of-existence) could work with an adversarial parent?
>
> Yes, DOE is denial of existence.  When the child sends NS queries
> as part of qname minimization a negative response (no NS records)
> will include signed NSEC(3) records to that effect, signed by the
> parent zone.  These are candidates for logging.
>

Understood now I think.


> The key question is how to avoid logging ridiculous volumes of
> data that can DoS any log service and also disclose too much.
>

+1 as this is logging NSEC(3) would make the logging rate proportional to
all RR churn.

Let put out an idea to attempt to mitigate this.  (And apologies ahead of
time if this is obviously wrong as I'm pretty new at DNS/DNSSEC)   For
this, the main thing this is trying to track is the existence of DS and its
DOE.  Why not create an explicit Non-existence of DS (NDS) RR that gets
logged along with DS and NS?  The effect is then is that every NS will then
have either a DS or NDS RR.   Then the rate of logging becomes proportional
to max of NS and DS changes.  I suspect NDS won't have the same enumeration
problems as the NSEC(3) since lacks next-signed link, and is paired with an
NS record anyways.  Also NDS does not change NSEC(3) behavior DOE behavior.
 (To be complete there could be a policy declaration mechanism for this but
that's details).

-Wei