On 20. 09. 21 18:12, Ben Schwartz wrote:
On Mon, Sep 20, 2021 at 10:53 AM Vladimír Čunát
<[email protected] <mailto:vladimir.cunat%[email protected]>> wrote:
Hello.
> If the parent zone also implements authenticated encryption, this
> provides sufficient protection for the glue records, but many
> important parent zones seem unlikely to implement authenticated
> encryption in the near future.
I'm not very convinced about the motivation so far. Let me look
top-down in the tree.
1: the root seems unlikely to support encryption, but we already do
have
ways of serving/prefetching the whole root zone locally including all
glue
I agree: local root (plus ZONEMD) is sufficient to authenticate root glue.
2: communication to TLD servers. I believe we have very
privacy-interesting data in QNAMEs there already, arguably even the
most
sensitive parts.
In general, I agree. However, there are some cases where the lower
labels are more sensitive (e.g. tumblr.com <http://tumblr.com>).
I do not dispute there are sites that might benefit, but I think we have
to keep the big picture in mind.
1] The second label is very often sensitive. To me, a non-sensitive
second label seems more of an exception.
2] Keep in mind that changing the domain name of an existing site is
next to impossible, so there is a lot of stuff firmly bolted to com. and
also other existing TLDs (and domains).
3] I guess .com itself contains roughly 1/2 of all second-level domains
on this planet. Consequently, if we design something that will not work
in com. for any reason (be it fragility, scalability, performance,
operational complexity or cost, ...), then we are practically doing
useless work.
All in all, while DSGLUE might offer some protection for some sites,
let's not overestimate its impact.
For this reason, I share Vladimir's skepticism.
Petr Špaček
...
And if a TLD offers
encrypted service, I can't see much use for the proposed DSGLUE, as we
got assurance because of the QNAMEs already.
There are two key reasons for DSGLUE: authentication and RR type
flexibility. In this model, it's not enough to secure the existing glue
RR types; we also need to convey the nameserver's ADoT configuration
during (in-bailiwick) delegation.
There seem to be many participants in the WG who believe that getting
new glue RR types into parent zones (and especially TLDs) is a very
distant prospect.
DSGLUE sure is way easier to implement and operate than encrypted
authoritative DNS, but I'd really hope that we can skip this step and
get (some) encrypted TLDs.
Yes, I think we will get *some*, but I think it will be a very long time
before we get *most*. Having an intermediate solution to protect lower
labels during that transition seems worthwhile to me.
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
