Apologies for the very late reply. I was out of the office for a longer
period of time. The rest is in-line.
On 23. 09. 21 20:17, Ben Schwartz wrote:
> On Thu, Sep 23, 2021 at 12:53 PM Petr Špaček <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 20. 09. 21 18:12, Ben Schwartz wrote:
>
> ...
>
> > 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>
> <http://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.
>
>
> I think this clarifies an important requirements question for the
> working group: do we intend to enable authenticated ADoT for names whose
> TLD doesn't do ADoT? If yes, we need a way to authenticate the NS name
> and a signal for ADoT support. If no, we can rely on the parent's ADoT
> to authenticate the glue (as suggested in draft-adox).
>
> 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.
>
>
> Are you saying that DSGLUE "will not work in com"? I'm not aware of any
> reason why this would be true. DSGLUE is designed to work without any
> changes to registries or TLDs.
>
> All in all, while DSGLUE might offer some protection for some sites,
> let's not overestimate its impact.
Yes, I claim that right now (as of version -02), DSGLUE cannot protect
80 % of sites in com.
Message
https://mailarchive.ietf.org/arch/msg/dns-privacy/xcc9MnJNlKNz0SDm7fRJkbtagfQ/
describes the problem with sibling glue which currently affects ~ 80 %
of com. domains.
For the remaining 20 % of domains, DSGLUE protects only second+ labels,
which might or might not be beneficial depending on the domain in question.
Fixing the sibling glue problem requires more thought and solving
possible policy questions mentioned in the message linked above.
> Consider this alternative framing: while sensitive-third-label domains
> may be rare overall, they certainly outnumber domains whose TLD supports
> ADoT, and that is likely to be true for at least several years.
> (Wikipedia says "As of May 2019, Tumblr hosts over 465 million blogs".)
Okay, that's a good point. It could even be argued domains that care
about DSGLUE might be required to avoid sibling glue. I'm not sure how
happy operators would be about that. That would be the next question.
> If you believe that most major TLDs will support authenticated ADoT and
> SVCB glue records within a few years, then we probably have all the
> pieces we need. Otherwise, I think we should add DSGLUE so we don't
> have to wait forever.
That's right, under the assumption that resolver vendors are happy to
implement DSGLUE and that registries are happy to accept DSGLUE RRs into
TLDs.
Do you have some indication that this is the case, ideally in comparison
with willingness of doing ADoT to TLD?
On a meta-level, I think DSGLUE provides somewhat uncertain benefits
while being very complex. For this reason, I'm not going to bet my money
on the speed of deployment of this. It might happen that by the time
DSGLUE is standardized & implemented & deployed by resolvers and
registries, "attackers" will implement the technique from the article
https://irtf.org/anrw/2019/anrw2019-final44-acmpaginated.pdf into a
turn-key solution. Doing so would render the "encrypt _just_ DNS"
approach moot (= huge waste of engineering resources).
Hopefully it clarifies my previous message.
--
Petr Špaček
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
