Subject: Re: [dns-privacy] [Ext] Review requested for DS glue (fwd)

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Sep 2021 15:37:20 -0400 (EDT)

Apologies, I mixed up the drafts during my reviews.

(cut out the me being confused part)

---------- Forwarded message ----------
Date: Wed, 15 Sep 2021 15:31:25
From: Paul Wouters <[email-masked]>

I believe this draft is not the best idea. It basically copies a lot of
"unsigned" data to turn it into a "signed" copy. The more obvious
approach would be to just provide a signature over the unsiged data in
the new DS variant record, which would reduce a lot of complexity.

A parent that wishes harm, eg wants to modify the unsigned data it has,
would be caught either way. A non-parent (forwarder in the middle)
should have no chance to forge anything to begin with because it should
require the child version of the NS RRset anyway, and thus already can
authenticate by checking existing DNSSEC signatures.

I am also not sure about the encodings here. It is not wire format and
it is mostly not presentation format. Why introduce a new format?

Section 4 contains a special DS record to disable DANE? I am not sure I
understand how and more importantly, where this works. If this is about
the child zone, then perhaps we should not give the parent zone the
power via DS records to make such statements about the child zone. Eg a
nation state could globally disable DANE by adding these special DS
records for all its delegations. It would be much better to encode some
SVCB style record into DS and have a child CDS record that can be used
to confirm the child's intent.

Section 5 says to not use DSGLUE without DNSSEC, but one has to wonder
what the gains are. If it can be used to find a more secure transport,
even without dnssec, why not? As the alternative is to not use the
record and use plain old insecure DNS with no known trust anchors
anyway?

It seems the IETF processes around encrypted DNS keep walking around
the elephant in the room. A few extra RTTs for privacy that focuses
on unrealistic privacy gains on in-baliwick nameservers TLS connection.

If you want real privacy gains from encrypted DNS, you have no choice
but to group yourself onto large DNS hosters anyway, and then the fact
that your reveal to talk to the large hosters DNS nameserver is a moot
point. This is all way too much complexity for no real operational
benefit.

Paul

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 15 Sep 2021 17:18:26 -0400

> the new DS variant record, which would reduce a lot of complexity.

That sounds a lot like
https://datatracker.ietf.org/doc/html/draft-dickson-dnsop-ds-hack-00.

I see two key advantages to the "verbatim" approach used in DS Glue.

1. It enables the provisioning of arbitrary RR types, without relying on
support from the parent (and registrar?) for each new RR type.

2. It greatly simplifies the rollover and validation logic.  With hashes in
DS, the glue and its hash can be out of sync, so the child zone operator
needs to publish records via a multi-phase commit process, and the resolver
needs to apply a lax validation rule to ignore some unmatched signatures.
Getting the lax validation logic correct, and ensuring that an attacker
cannot remove any glue records without detection, is very difficult.  (It
also relies on the parent implementing a very consistent glue policy, e.g.
things might break if the parent starts adding sibling glue.)

It may be possible to make this work, but I don't think it would reduce
complexity.

...

> it is mostly not presentation format. Why introduce a new format?

The records inside DS Glue are each in wire format, but perhaps you're
pointing out that the DS Glue collection is not in DNS message format.
This is only to save space, as the DNS message format contains a lot of
redundancy (e.g. repeating the TTL, class and type for every RR), and it's
valuable to avoid making delegation responses larger than necessary.

Section 4 contains a special DS record to disable DANE?

It's not "special", exactly.  DSGLUE can encode any RRSet, including an
empty set, of any RR type, anywhere below the zone cut.  Section 4.4.1
shows an example of encoding an empty TLSA RRSet that short-circuits the
TLSA lookup during delegation.

I am not sure I
> power via DS records to make such statements about the child zone.

These are glue records, so they only apply during delegation-following.  As
such, they are only relevant to nameserver connection establishment.

> Eg a
> records for all its delegations.

It can't disable DANE "in general".  It could disable DANE-authenticated
ADoT, but it could just as easily disable ADoT by changing the NS names.

> It would be much better to encode some

We don't need to use CDS for this, because the actual authoritative
versions of all these glue records should exist in the child zone, and the
resolver can revalidate them (just like NS revalidation).  A resolver could
even revalidate the glue records synchronously (i.e. before issuing the
main query), but for performance reasons this seems like an unlikely
resolver behavior.

> record and use plain old insecure DNS with no known trust anchors

You're more or less right.  My main concern here is that some record types
are likely unsafe to accept if they are not properly authenticated.  (Also,
I want to encourage DNSSEC.)

> point. This is all way too much complexity for no real operational

I think there's a misunderstanding here.  The goal is not to conceal the
name of the nameserver.  That is assumed to be public, and will generally
be revealed in the TLS SNI.

The goal of ADoT is to conceal the actual QNAME.  To do this, the resolver
needs to learn at least one bit of information before it issues the main
query: does this nameserver support ADoT?  If it doesn't learn that from
the parent, then it has to spend an extra roundtrip before the main query
to perform a "synchronous check" at every uncached zone cut in the QNAME.
My impression from talking to resolver operators is that this is a
performance cost that they are not willing to accept.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Sep 2021 21:13:13 -0400 (EDT)

On Wed, 15 Sep 2021, Ben Schwartz wrote:

> That sounds a lot like https://datatracker.ietf.org/doc/html/draft-dickson-dnsop-ds-hack-00.

Yes, it has come up a number of times in the WG in the last two years.

> 1. It enables the provisioning of arbitrary RR types, without relying on support from the parent (and registrar?) for each
> new RR type.

I'm not sure this is a good thing. A child could encode things and get
the parent to publish arbitrary data (eg via an embedded TXT in DSGLUE).
Granted you can probably do that with SVCB-encoded-in-DS as well, but
there the Registries at least can look for the matching SVCB at the
child and limit it to valid syntax for transport information.

Putting a sort of compressed wireformat inside a parental record is
putting things at the extreme end of RR overloading. It is a whole
DNSoverRR protocol.

> 2. It greatly simplifies the rollover and validation logic.  With hashes in DS, the glue and its hash can be out of sync,
> so the child zone operator needs to publish records via a multi-phase commit process, and the resolver needs to apply a lax
> validation rule to ignore some unmatched signatures.

Once you update via CDS/CDNSKEY, you are looking at fully autonomous
rolls. Add ACME into that system and it is all an automated system.
Sure they might be bugs in the software, but those will work itself
out, unlike humans in the chain.

> (It also relies on the parent implementing a
> very consistent glue policy, e.g. things might break if the parent starts adding sibling glue.)

See the recent glue-is-not-optional draft, where we are strongly
advocating a MUST for all glue (whether sibling or not). That would
give you a nice consistent NS RRset. I do agree that too often the
parent and child NS RRset is out of sync, but in that case you now
have a bigger problem. Which source do you believe? The Registrar/EPP
data published by the parent, or the child stuffed DSGLUE pushed to
the parent?

> The records inside DS Glue are each in wire format, but perhaps you're pointing out that the DS Glue collection is not in
> DNS message format.  This is only to save space, as the DNS message format contains a lot of redundancy (e.g. repeating the
> TTL, class and type for every RR), and it's valuable to avoid making delegation responses larger than necessary.

Why does space matter? The connection getting this data better be over
TLS already, at which point size is pretty much irrelevant?

> It's not "special", exactly.  DSGLUE can encode any RRSet, including an empty set, of any RR type, anywhere below the zone
> cut.  Section 4.4.1 shows an example of encoding an empty TLSA RRSet that short-circuits the TLSA lookup during delegation.

A "hacked DS" with no encrypted transport options from SVCB embedding
would do the same, but it would be limited to only that. Your DSGLUE
can have any kind of list of RRs. You say "should be glue and/or related
to (encrypted) transport, but that is not really enforced in the
specification. It's like a mini-cache in the parent of who knows what.

> These are glue records, so they only apply during delegation-following.  As such, they are only relevant to nameserver
> connection establishment.
>  
>       Eg a
> It can't disable DANE "in general".  It could disable DANE-authenticated ADoT, but it could just as easily disable ADoT by
> changing the NS names.

True.

> We don't need to use CDS for this, because the actual authoritative versions of all these glue records should exist in the
> child zone, and the resolver can revalidate them (just like NS revalidation).  A resolver could even revalidate the glue
> records synchronously (i.e. before issuing the main query), but for performance reasons this seems like an unlikely
> resolver behavior.

Seeing how the point is cutting corners and fancy hacks to save an RTT,
that does worry me. And again, the use case for this is very limited
too. Especially if this resolver is itself part of a Doh/DoT group where
this means 1 RTT (or even one timeout) per nameserver name (not per
domain, but per nameserver name). We already had this exact problem
before with EDNS queries getting lost, and all resolvers kept track of
nameservers that failed EDNS for a while to avoid too many timeout
periods. I honestly don't think the problem you are solving is worth
this complexity.

> You're more or less right.  My main concern here is that some record types are likely unsafe to accept if they are not
> properly authenticated.  (Also, I want to encourage DNSSEC.)

Well the point is moot I guess. Any zone publishing DS records better
uses DNSSEC to sign these. And since there is only one RRSIG over the
entire DS set, the DS $DSGLUE one is always signed along with the real
DS records (if any). If the DS RRset is not signed, the validator will
treat the data as BOGUS and not return it to the client.

> I think there's a misunderstanding here.  The goal is not to conceal the name of the nameserver.  That is assumed to be
> public, and will generally be revealed in the TLS SNI.
> 
> The goal of ADoT is to conceal the actual QNAME.

I agree about ADoT. I do not agree about DSGLUE.

None of this is needed to protect the QNAME that is not in-bailiwick,
when using query minimalization. If the client wants to know the A
record of libreswan.org, and it connects to the .org nameserver over
encrypted transport, it can ask for NS libreswan.org, and get the
NS records, eg ns0.nohats.ca. Your argument is that trying ADoT to
ns0.nohats.ca is an operational issue because you have to wait for
a timeout. My argument is that for domains hosted on ns0.nohats.ca (there
are about 15), there is no real expectation of privacy for QNAME even
if the transport to ns0.nohats.ca is perfectly encrypted with no SNI leaks.

To truly gain anonimity, you need the nameservers to host thouands of
domains to hide with. At that point, saving one RTT/timeout for
ns0.bighoster.com becomes pretty meaningless. And my argument is that
this complexity is not worth that one RTT/timeout.

>  To do this, the resolver needs to learn at least one bit of information
> before it issues the main query: does this nameserver support ADoT?

In my view, the resolver already knows this nameserver. If this
nameserver is so uqniue to the QNAME that it is not almost always
already in its cache, you already lost your privacy anyway.

> If it doesn't learn that from the parent, then it has
> to spend an extra roundtrip before the main query to perform a "synchronous check" at every uncached zone cut in the
> QNAME.  My impression from talking to resolver operators is that this is a performance cost that they are not willing to
> accept.

They don't really need to. ns0.bighoster.com does not need privacy. Just
resolve like normally, and in parallel sent a TLSA or SVCB query for
the nameserver's encrypted transport information for future use. Use
prefetching when its TTL is low but not yet expired. It will always be
fresh in the cache.

Don't treat QNAMEs of NS record lookups as secrets. They are not.

Paul

---

From: Peter van Dijk <[email-masked]>
Date: Tue, 21 Sep 2021 13:34:45 +0200

On Wed, 2021-09-15 at 17:18 -0400, Ben Schwartz wrote:
> 1. It enables the provisioning of arbitrary RR types, without relying on support from the parent (and registrar?) for each new RR type.

Yes, but: for all (three?) proposals that are going around for 'using
DS to strengthen NS names', deployment would be best with registrar
support. Yes, zone owners can upload DS records to match/hash their
NSes, but it would be way cooler if the registry emitted those DS
records automatically. However, this is not a deployment requirement.

> 2. It greatly simplifies the rollover and validation logic.  With hashes in DS, the glue and its hash can be out of sync, so the child zone operator needs to publish records via a multi-phase commit process, and the resolver needs to apply a lax validation rule to ignore some unmatched signatures.  Getting the lax validation logic correct, and ensuring that an attacker cannot remove any glue records without detection, is very difficult.  (It also relies on the parent implementing a very consistent glue policy, e.g. things might break if the parent starts adding sibling glue.)

+1 to this. Getting the data unhashed-but-signed from the parent
simplifies so many things.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/