Subject: Re: [dane] [Trans] CT for DNSSEC

From: Paul Wouters <[email-masked]>
Date: Mon, 3 Apr 2017 15:44:59 -0400 (EDT)

On Wed, 29 Mar 2017, Viktor Dukhovni wrote:

>> Why not create an explicit Non-existence of DS (NDS) RR that gets logged along with DS and NS?
>
> This is not needed, the NSEC/NSEC3 RRs already serve that role.
>
> For NSEC records (RFC4034), an unsigned delegation looks like:
>
> 	example.com. IN NS ns1.example.com.
> 	example.com. IN NSEC examplf.com NS
> 	example.com. IN RRSIG NSEC ...
>
> this proves that NS (or other depending on the content of the type
> bitmap of the NSEC record) records exist for example.com, but DS
> records do not.

I don't think so? Because this is the parental NS RRset for the child,
which the parent does not sign. The NSEC only covers the existance of
the DS record, not of the glue records. And those glue records can
still be maliciously pointing elsewhere. Or the zone cut can be
temporarilly removed at the parent to sign the child's TLSA record
directly.

You really need to find the NSEC(3) record that proves the parent has
no DS record for the child zone, and really have to find and submit
the TLSA record and RRSIG. That way the logs can tell who signed the
DS and/or TLSA record.

Checking the child APEX is of no use because the parent might be
overriding the delegation briefly. Eg remove the DS record and/or
NS records, publish a childzone TLSA record as "without a zone cut",
and then restoring the DS/NS chain again.

The only way out I see is to log the TLSA records, so you know which
key signed it. If this is done, we clearly need a ratelimit and/or
some method of finding conflicting overlapping-in-time records.

> With NSEC3 (rfc5155), and the "opt-out" bit the situation can be
> more complex because the answer may not establish the existence of
> example.com.  Instead we may get an existence proof for the closest
> encloser (ancestor domain) and proof that "example.com" is not signed,
> but no proof of its existence.  This means that to avoid spam, a log
> might want to independently verify the existence of the insecure
> delegation by repeating the query, so as to avoid storing data for
> non-existent domains with the insecure NXDOMAIN modified to NOERROR
> with made up NS records.

Repeating the query is not a real solution, as the malicious parent
could open a small time window for the attack and close it again.
Clients really need to submit state their validation reached. This
cannot include any unsigned state as that cannot be trusted itself,
but should include the signatures proving the unsigned state.

Paul

---

From: Tony Finch <[email-masked]>
Date: Tue, 4 Apr 2017 10:51:27 +0100

Paul Wouters <[email-masked]> wrote:
>
> Because this is the parental NS RRset for the child, which the parent
> does not sign.

Right.

> The NSEC only covers the existance of the DS record, not of the glue
> records.

Not quite. A delegation NSEC record lists NS NSEC RRSIG and maybe DS, even
though NS isn't signed. (You are right that glue records aren't in the
NSEC chain, though.)

> the TLSA record and RRSIG. That way the logs can tell who signed the

Yes. Should probably log the whole DS/DNSKEY/RRSIG chain. You don't need
to log NSEC(3) unless you need to log a proof of nonexistence - maybe to
prove lack of delegation points if there are intermediate labels?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Fitzroy: Northerly veering northeasterly 4 or 5, increasing 5 to 7 in east.
Rough or very rough. Drizzle. Moderate or good.

---

From: Wei Chuang <[email-masked]>
Date: Wed, 12 Apr 2017 09:48:55 -0700

On Wed, Mar 29, 2017 at 8:11 AM, Viktor Dukhovni <[email-masked]>
wrote:

>
> > On Mar 29, 2017, at 10:33 AM, Wei Chuang <[email-masked]> wrote:
> >
Sorry this reply is coming late.  Your response helped a lot (thanks!) but
I had nagging concern that couldn't make concrete till now.

When a DOE lookup occurs on DNSSEC, the authoritative nameserver services
the request and determines to respond with what you describe above (the
NSEC and its RRSIG).  The complication occurs with CT.  While we may log
the NSEC or NSEC3 record and these records will be present for lookups in
CT of existing records, there isn't an online server to assist with lookups
in CT of non-existing records.  I suppose it may be possible to replicate
the state of the authoritative nameserver but consider that this likely
doesn't scale as CT servers are servicing a scope potentially much larger
than the authoritative nameservers.  The approach I describe earlier with
an explict Non-existence of DS (NDS) should allow for direct lookup of NDS
entry.

Also agreed with later comments suggesting that the entire key signing
chain needs to be CT logged with its proofs and non-existance records for
this to work.

-Wei

> --
>         Viktor.
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>