On Wed, 24 Feb 2021, Eric Rescorla wrote:
You talk about adding SVCB to the additional data, but in practise
authoritative prefer small lean answers these days to avoid
amplification attacks, so I'm not sure if this is a reasonable
assumption of the future.
A basic assumption here is that you are doing TLS to the referring
authoritative. Otherwise things kind of fall apart for reasons laid
out in the security considerations. So in this case I would assume
that amplification is much less of an issue.
It would be interesting to know if implementors of current DNS software
already use different strategies for populating the Additional Section
based on the transport (UDP, UDP with COOKIE, TCP).
> - The basic assumption is that the transport to the parent [0]
> is encrypted, thus preventing attackers from substituting
> NS or SVCB [1].
SVCB is not served by the parent right? You mean the substitution
would be in a second step after substituting the NS records?
I was assuming SVCB was served by the parent in additional_data.
But as a practical matter, substituting NS works as well.
Oh. I don't see how that can really be done. Because .ca has no way
to publish something for ns0.nohats.ca. You would basically be creating
a new type of GLUE record. That would need support in EPP, RDAP, all
the Registrar WebGUI's etc etc. I don't think that is realistic.
Additionally, you would be serving out of zone data on an authoritative
server. Which is quite different from a recursive server that is giving
you additional data from a different zone than the QNAME, because it
knows you'll ask for it anyway (and it has that data in its cache).
The auth server has no cache. It would require new code. Again, I don't
think that is realistic. You'd be better of encoding this into another
NS record or DS record - which has been proposed in the past.
And the defense against this is of course verifying any NS record
using the signed DS record at the parent and confirming the records at
the child. This costs an extra lookup but gains you security.
Does that work for this case? My reasoning was that it was too late.
For instance, you're looking up example.com and you receive
NS=ns.attacker.example.
At this point (1) the attacker knows you want example.com and (2) you then have
to query ns.attacker.com for the signed NS records, so ns.attacker.com learns
it (even if you didn't already know). So this is useful for concealing whether
you want a.example.com or b.example.com, but not if the only domains anyone
wants are www.example.com and example.com, right?
It's the price to pay. The only way to avoid that is the somehow encode
the public key of the nameserver in the parent zone, so that you can
verify the TLS connection _before_ you send the DNS query for the target
domain. That works for all zones other than where the nameserver lives
in the same zone (eg TLS to ns0.example.com always reveals you want to
talk to example.com, but TLS to ns0.largeisp.com does not reveal which
domain you are going to query for).
We went through that discussion with overloading the DS record. I
pointed out that there is another attack you need to defend against in
that case. If the TLD is untrustworthy and adds DS records pointing to
its own nameservers that will forward your queries, they will still see
everything. And if you hardware TLS they can censor you as well. The
way out of that is to verify the DS record and the parent with a CDS
copy of the record at the nameserver, and only continue with your real
DNS query after confirmation. This at least forces the rogue parent
to have to modify the DS record set, which we could run DNSSEC
Transparancy on.
It seemed the DS record idea stalled, because the authors didn't really
like the additional RTTs needed. I still think it is the least worst
solution to authenticat the path from parent to child nameserver,
without introducing new RRTYPEs that require new procesing rules
that take years to deploy.
Paul
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
