On Wed, 15 Sep 2021, Ben Schwartz wrote:
On Wed, Sep 15, 2021 at 3:37 PM Paul Wouters <[email protected]> wrote:
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.
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.
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.
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?
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.
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
nation state could globally disable DANE by adding these special DS
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.
True.
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.
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.
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?
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.
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.
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
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
