[dane] CT for DNSSEC

[Wei Chuang]

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

[Paul Hoffman]

Post by Wei Chuang
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?

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

[Wei Chuang]

Post by Wei Chuang
I saw there was significant interest

Post by Wei Chuang
<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?

- 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.

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.

Post by Wei Chuang
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

Post by Wei Chuang
--Paul Hoffman

[Paul Hoffman]

Post by Wei Chuang

Post by Wei Chuang
I saw there was significant interest

Post by Wei Chuang
<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?

- 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.

Is this because you're worried about the parent removing evidence of DNSSEC
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.

Post by Wei Chuang
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.

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

Post by Wei Chuang
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.

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

Post by Wei Chuang
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.

Post by Wei Chuang

Post by Wei Chuang
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.

--Paul Hoffman

[Wei Chuang]

One issue with logging all records seen is if webmail providers publish

Post by Paul Hoffman

Post by Wei Chuang
SMIMEA there will be a potentially overwhelming number of records logged,
and a very large change rate.

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.

Post by Paul Hoffman
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.

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

[Wei Chuang]

Post by Wei Chuang

Post by Paul Hoffman

Post by Wei Chuang
Is this because you're worried about the parent removing evidence of

DNSSEC

Post by Paul Hoffman

Post by Wei Chuang
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.
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-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)

Post by Wei Chuang
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...

I agree.

-Wei

Post by Wei Chuang
--
Viktor.
_______________________________________________
Trans mailing list
https://www.ietf.org/mailman/listinfo/trans

[Wei Chuang]

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

Post by Wei Chuang

Post by Wei Chuang

Post by Paul Hoffman
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

[Paul Wouters]

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.
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

[Tony Finch]

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.)

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.

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.

[Wei Chuang]

Post by Wei Chuang

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.
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.

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

Post by Wei Chuang
--
Viktor.
_______________________________________________
dane mailing list
https://www.ietf.org/mailman/listinfo/dane

[Linus Nordberg]

Post by Wei Chuang
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?

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

[Wei Chuang]

Post by Linus Nordberg

Post by Wei Chuang
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

Post by Wei Chuang
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

Post by Wei Chuang
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].

Oh cool. Taking a look.

Did things just pause due to benign neglect?

-Wei

Post by Linus Nordberg
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+vqfg2O3ZbVYvlMxof2dzLwJ09gPtdY
3FGtq1LbaAIgXWD4qfCOh38JzCz52E1B1cdkI+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