Subject: [dane] CT for DNSSEC

From: Wei Chuang <[email-masked]>
Date: Thu, 16 Mar 2017 10:09:44 -0700

Hi folks,

I saw there was significant interest
<http://blog.huque.com/2014/07/dnssec-key-transparency.html> in exploring
CT for DNSSEC back in 2014 of which a draft draft-zhang-trans-ct-dnssec
<https://tools.ietf.org/html/draft-zhang-trans-ct-dnssec-03> was created.
It seems to have quieted down since.  I believe the motivation is still
there which is to prevent a parent zone from potentially misbehaving and
spoofing the child zone.  Is there still interest in this?  From the list
archives, I can't see what the issues were though I'm guessing one of them
was respecifying the DS resource record to use a SCT which might have
caused compatibility concerns.  (But please correct me if I'm wrong)  Other
than that, the draft seems pretty reasonable.  Were there other concerns?

thanks,
-Wei

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 16 Mar 2017 10:25:08 -0700

> than that, the draft seems pretty reasonable.  Were there other 

There were two separate issues that got conflated at the time:

- Seeing evidence that a parent had spoofed DNSSEC keys for a child. A 
transcript of the DS records in the parent is sufficient as long as the 
child doesn't have relying parties create islands of trust (which is 
relatively rare these days).

- Seeing evidence that a parent had spoofed any resource records for a 
child. A transcript of the NS records in the parents is a good start, 
although what is really needed is a transcript of everything that is 
seen for the child.

In both cases, having transcripts from various DNS looking glasses 
around the Internet would give greater assurance of the integrity of the 
transcript.

--Paul Hoffman

---

From: Linus Nordberg <[email-masked]>
Date: Fri, 17 Mar 2017 09:54:46 +0100

Wei Chuang <[email-masked]> wrote

> than that, the draft seems pretty reasonable.  Were there other concerns?

I'm still interested in logging things DNSSEC. The test log set up at
the IETF Berlin hackathon [0] is still running [1]. We lack a client for
submission.

Protocol deviations from draft-zhang-trans-ct-dnssec-03 are summarized
in [2].

[0] https://lists.sunet.se/pipermail/dnssec-transparency/2016-July/000049.html
[1] curl -A "" -x socks4a://127.0.0.1:9050/ -s http://teowuafdvio2mip5.onion/dt/v1/get-sth | json_pp
--8<---------------cut here---------------start------------->8---
{
   "tree_head_signature" : "BAMARjBEAiA48+vqfg2O3ZbVYvlMxof2dzLwJ09gPtdY3FGtq1LbaAIgXWD4qfCOh38JzCz52E1B1cdkI+8+gHitA1DNMC4Zl2g=",
   "timestamp" : 1489739801931,
   "tree_size" : 1,
   "sha256_root_hash" : "OQFz17e1piHRfRRsAG3QkweRuq/jyrjViq+vZbkyY+I="
}
--8<---------------cut here---------------end--------------->8---
[2] https://git.nordu.net/?p=user/linus/catlfish.git;a=blob_plain;f=README-dnssec.md;hb=refs/heads/dnssec2

---

From: Wei Chuang <[email-masked]>
Date: Fri, 17 Mar 2017 09:31:44 -0700

On Thu, Mar 16, 2017 at 10:25 AM, Paul Hoffman <[email-masked]>
wrote:

> although what is really needed is a transcript of everything that is seen
> for the child.
>

Is this because you're worried about the parent removing evidence of DNSSEC
for the child in the spoofing scenario?  If the parent tries to spoof with
DNSSEC for the child I would assume that seeing the DS SCT's in the log,
that is sufficient to find evidence of spoofing.  That said I think it
could be helpful to log NS as well for forensics.

One issue with logging all records seen is if webmail providers publish
SMIMEA there will be a potentially overwhelming number of records logged,
and a very large change rate.  Another issue is privacy of such records.

>
> In both cases, having transcripts from various DNS looking glasses around
> the Internet would give greater assurance of the integrity of the
> transcript.

I agree that would a good idea.

-Wei

---

From: Wei Chuang <[email-masked]>
Date: Fri, 17 Mar 2017 09:34:39 -0700

On Fri, Mar 17, 2017 at 1:54 AM, Linus Nordberg <[email-masked]> wrote:

> the IETF Berlin hackathon [0] is still running [1].

Oh cool.  Taking a look.

Did things just pause due to benign neglect?

-Wei

> We lack a client for

> [1] curl -A "" -x socks4a://127.0.0.1:9050/ -s
> http://teowuafdvio2mip5.onion/dt/v1/get-sth | json_pp
>    "tree_head_signature" : "BAMARjBEAiA48+vqfg2O3ZbVYvlMxof2dzLwJ09gPtdY
> 3FGtq1LbaAIgXWD4qfCOh38JzCz52E1B1cdkI+8+gHitA1DNMC4Zl2g=",
> [2] https://git.nordu.net/?p=user/linus/catlfish.git;a=blob_
> plain;f=README-dnssec.md;hb=refs/heads/dnssec2
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 17 Mar 2017 11:20:06 -0700

On 17 Mar 2017, at 9:31, Wei Chuang wrote:

>> seen
> for the child in the spoofing scenario?

No, this is because the parent can spoof any data for the child. It is 
unrelated to DNSSEC.

> If the parent tries to spoof with

Transcripts are useful even when the logged data is not cryptographic.

> and a very large change rate.

Don't log what you can't log due to scale.

> Another issue is privacy of such records.

Sure, but there are unpredictable privacy issues with lots of DNS record 
data. It's not possible for us to predict what will and will not be 
considered private information now or in the future for anyone other 
than ourselves.

>> around

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 17 Mar 2017 14:46:28 -0400

> On Mar 17, 2017, at 2:20 PM, Paul Hoffman <[email-masked]> 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.  So logging can be limited
to NS/DS queries, but that still leaves us with the problem of how
to avoid logging non-existence of NS/DS for all the sundry leaf
nodes. The public suffix list might be a useful resource here...

-- 
	Viktor.

---

From: Wei Chuang <[email-masked]>
Date: Mon, 20 Mar 2017 15:38:49 -0700

> Don't log what you can't log due to scale.

Just a note of caution: Sometimes that might be hard to determine a priori
deployment, and then the cause of cessation of logging might be
inadvertently interpreted as malicious.  It might be best to statically
define which records are expected to be logged.

> considered private information now or in the future for anyone other than
> ourselves.

Logging may defeat the privacy mechanism that SMIMEA and OPENPGPKEY naming
scheme uses to prevent bulk disclosure of keys i.e. sec 7.4 in RFC7929.
Much depends on the log implementation though.

-Wei

---

From: Wei Chuang <[email-masked]>
Date: Mon, 20 Mar 2017 15:43:20 -0700

On Fri, Mar 17, 2017 at 11:46 AM, Viktor Dukhovni <[email-masked]>
wrote:

> for logging than routine non-NS queries.

Can you expand on how the the DOE record (which I assumes means
denial-of-existance) could work with an
adversarial parent?

The only approach I can think of is some sort of UI support which isn't
very compelling.  (Perhaps monitors
but alas I not really up-to-date where things are at with monitors and
gossip)

>   So logging can be limited

I agree.

-Wei

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 20 Mar 2017 19:00:56 -0400

> On Mar 20, 2017, at 6:43 PM, Wei Chuang <[email-masked]> wrote:
> 
> 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.

An insecure positive response will include NSEC(3) records proving
the non-existence of the DS RRset (possibly via the opt-out flag).
These can also be logged.

A secure positive response, can also be logged, and the follow-up
query for any associated DS records will again either yields an
answer that can be logged, or DOE that can be logged.

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

Hence the suggestion to consider using the PSL as a cut-off
mechanism.  One would also not log NXDOMAIN responses to NS,
which might allow parent domains to lie about non-existence,
but is surely necessary to guard against filling logs with
junk.

There are likely many issues this fails to consider, but I
think that's a reasonable starting point to explore further.

-- 
	Viktor.

---

From: Wei Chuang <[email-masked]>
Date: Wed, 29 Mar 2017 09:33:02 -0500

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

> parent zone.  These are candidates for logging.

Understood now I think.

> 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

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Mar 2017 11:11:40 -0400

> On Mar 29, 2017, at 10:33 AM, Wei Chuang <[email-masked]> 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.

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.

-- 
	Viktor.