Subject: Re: [dns-privacy] Review requested for DS glue

From: Brian Haberman <[email-masked]>
Date: Fri, 1 Oct 2021 07:50:58 -0400

Hi Ben,

On 9/23/21 2:17 PM, Ben Schwartz wrote:
> On Thu, Sep 23, 2021 at 12:53 PM Petr Špaček <[email-masked]> 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>).
>>
>> 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).

I purposely waited a week to see if anyone would venture an answer to
this query. From my perspective, as co-chair, the lack of an answer is
quite telling. To me, it indicates that the WG is still not sure where
it wants to go with this work. I would contend that the only consistent
view I have heard from everyone is that there is not a need to
authenticate or encrypt to the root servers. After that, I see a lack of
consensus on:

1. ADoT support at TLDs
2. ADoT support at parents for children doing ADoT

Granted, in most cases #1 is a degenerate case of #2.

Regards,
Brian

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 1 Oct 2021 15:07:25 +0000

On Oct 1, 2021, at 4:50 AM, Brian Haberman <[email-masked]> wrote:
> it wants to go with this work.

If "this work" means authenticated ADoT, I agree. If "this work" means "DS glue", I disagree. The presence of DS glue for resolvers that are doing unauthenticated DoT allows for more encryption of DNS on the Internet.

> I would contend that the only consistent

Given that, can we move forward with the unauthenticated use case, for which there has been a lot of interest? Or do we have to reach consensus on one use case for both of them to move forward?

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Fri, 1 Oct 2021 11:37:43 -0700

On Fri, Oct 1, 2021 at 8:07 AM Paul Hoffman <[email-masked]> wrote:

> If "this work" means authenticated ADoT, I agree. If "this work" means "DS
> glue", I disagree. The presence of DS glue for resolvers that are doing
> unauthenticated DoT allows for more encryption of DNS on the Internet.
>

Is there a document on the requirements for unauthenticated DoT, or a
comparison of things ADoT offers that unauthenticated's use case could be
handled by just ignoring some of those ADoT features?

As for "DS glue" (specifically the draft in DPRIVE with that name), there
is a vaguely similar draft by me in DNSOP that does a similar single thing
that is slightly similar to ds-glue, where the differences are important.

The "one thing" in the DNSOP draft is "supply DS record(s) that correspond
to NS records present at the parent, via new DNSKEY algorithm and existing
DS hash algorithms, intended to only validate/verify the published NS
records in the parent". This is consistent with the general policies
related to ICANN TLDs and use of DNSSEC records (which validate/verify
delegations and do not do anything else that impacts TLD policies, which I
believe are generally mandated by ICANN under Registry contracts.

What "DS glue" is proposing seems to me to be a significant departure from
existing TLD usage and policies, in particular publishing new DATA in the
DS records that preempts existing published data, using new DS algorithms
that the TLDs all need to support for it to be useful.

My concern is that the relationships between the larger organizations
(IETF, ICANN, Registries), where there are formal channels for asking
questions and proposing changes, may require obtaining permission in
advance of proposing significant policy changes.

I'd suggest that the authors and chairs discuss this with the AD, IESG, and
get a read on this from the IAB. There may be a need to consult with
various liaisons or via liaisons to the other organizations, to determine
if this is okay to do without any actual changes to official policy
documents, or if it would require policy level changes. At a minimum, even
without the liaison work, getting an informal buy-in from the major gTLD
registry operators is a crucial step.

Brian Dickson

> Given that, can we move forward with the unauthenticated use case, for
> which there has been a lot of interest? Or do we have to reach consensus on
> one use case for both of them to move forward?
>
> --Paul Hoffman_______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Brian Haberman <[email-masked]>
Date: Mon, 4 Oct 2021 08:29:08 -0400

Hi Paul,

> If "this work" means authenticated ADoT, I agree. If "this work" means "DS glue", I disagree. The presence of DS glue for resolvers that are doing unauthenticated DoT allows for more encryption of…

Sorry for the lack of clarity. I specifically meant the ADoT work.

> Given that, can we move forward with the unauthenticated use case, for which there has been a lot of interest? Or do we have to reach consensus on one use case for both of them to move forward?

I see no reason to slow the effort on the unauthenticated use case.

Regards,
Brian

---

From: Petr Špaček <[email-masked]>
Date: Fri, 8 Oct 2021 12:50:52 +0200

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-masked]
 > <mailto:[email-masked]>> wrote:
 >
 >      > labels are more sensitive (e.g. tumblr.com <http://tumblr.com>
 >     <http://tumblr.com <http://tumblr.com>>).
 >
 > 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