Subject: [dns-privacy] WG strategy on opportunistic vs authenticated moving forward

From: Tim Wicinski <[email-masked]>
Date: Mon, 12 Jul 2021 13:12:21 -0400

All,

The chairs have been watching the working group while we prepare for the
upcoming meeting, and working through the proposals and arguments that keep
coming up. We feel there is strong consensus to work on opportunistic
encryption and that it may be beneficial to discuss possible experimental
deployments with a version of the currently documented approach
(draft-ietf-dprive-unauth-to-authoritative).

The concern with lumping the root, TLDs, and SLDs into one solution is that
there are contractual issues with what can be in a zone above an SLD. These
limitations are potentially an issue with some solutions that need/want new
records in the parent’s zone. We feel like the WG will not be able to make
additional progress on any of the proposed solutions until we can reach
consensus on whether the solution should be homogeneous from the root down
or that the real focus is on SLDs and down.

We've asked Paul and Petr to not focus on the common-features document and
move that content  back into their draft.  The authors of
draft-rescorla-dprive-adox-latest will be incorporating concepts from
draft-schwartz-dprive-name-signal as a next step for the authenticated
encryption proposal. This should provide a more concrete proposal that can
be considered for WG adoption.

The chairs would like to solicit any input/feedback on the above as we
prepare for our session during IETF 111.

Tim & Brian

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 12 Jul 2021 20:50:17 +0100

Hiya,

On 12/07/2021 18:12, Tim Wicinski wrote:
> there are contractual issues with what can be in a zone above an SLD. 

I agree that different solutions will be needed for those
three quite different kinds of zone.

Personally, I think that qname minimisation is fine for
the root for now. If we do better later, that'll be good
but oughtn't block us, particularly from experiments.

Opportunistic TLS (or better) for SLDs and below seems
doable, again for experiments.

For TLDs, I'd hope we can find some that don't have
those contractual issues and that are willing to be part
of some experiments.

And I'd hope as those experiments proceed we gain enough
experience to maybe fill in the missing parts of the puzzle.

The biggest missing part of the puzzle with the above
will be exposing the qname when querying the most commonly
used TLDs, but I think we can do useful experiments while
that's figured out. (And as you say, the figuring there
has some non-technical trickiness.)

Cheers,
S.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 13 Jul 2021 15:08:18 +0000

From: dns-privacy <[email-masked]> On Behalf Of Tim Wicinski
Sent: Monday, July 12, 2021 1:12 PM
To: DNS Privacy Working Group <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] [dns-privacy] WG strategy on opportunistic vs authenticated moving forward

Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

All,

The chairs have been watching the working group while we prepare for the upcoming meeting, and working through the proposals and arguments that keep coming up. We feel there is strong consensus to work on opportunistic encryption and that it may be beneficial to discuss possible experimental deployments with a version of the currently documented approach (draft-ietf-dprive-unauth-to-authoritative).

The concern with lumping the root, TLDs, and SLDs into one solution is that there are contractual issues with what can be in a zone above an SLD. These limitations are potentially an issue with some solutions that need/want new records in the parent’s zone. We feel like the WG will not be able to make additional progress on any of the proposed solutions until we can reach consensus on whether the solution should be homogeneous from the root down or that the real focus is on SLDs and down.

We've asked Paul and Petr to not focus on the common-features document and move that content  back into their draft.  The authors of draft-rescorla-dprive-adox-latest will be incorporating concepts from draft-schwartz-dprive-name-signal as a next step for the authenticated encryption proposal. This should provide a more concrete proposal that can be considered for WG adoption.

The chairs would like to solicit any input/feedback on the above as we prepare for our session during IETF 111.

[SAH] Knowing that there are concerns from the root server operators and operators of some top-level domains about both the server resource overhead of adding support for encryption and the value proposition in doing so, my preference would be for the WG to focus on solutions for authoritative name servers serving zones that aren’t delegation-centric. The recursive-to-authoritative resolution environment is already heterogeneous, and data minimization techniques (such as QNAME minimization) are available to reduce information disclosure during exchanges at the delegation-centric levels. There may be more interest in experimentation using non-delegation-centric zones and name servers where the data minimization techniques aren’t available, and those experiments can help guide the “increased deployment in other parts of the DNS hierarchy” mentioned in the statement from the root server operators [1].

[1] https://root-servers.org/media/news/Statement_on_DNS_Encryption.pdf

Scott

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 13 Jul 2021 15:33:57 +0000

On Jul 13, 2021, at 8:08 AM, Hollenbeck, Scott <shollenbeck=[email-masked]> wrote:
> . . .my preference would be for the WG to focus on solutions for authoritative name servers serving zones that aren’t delegation-centric.

This has come up before, and I'm trying to figure out why. If this WG comes up with a protocol that any zone operator can choose to implement, why differentiate between delegation-centric and anything else? It feels short-sighted to look at current zone contents and try to optimize a solution for them, instead of just making all DNS extensions optional.

--Paul Hoffman

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 13 Jul 2021 15:56:58 +0000

> -----Original Message-----
> From: dns-privacy <[email-masked]> On Behalf Of Paul
> Hoffman
> Sent: Tuesday, July 13, 2021 11:34 AM
> To: [email-masked]
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] WG strategy on opportunistic vs
> authenticated moving forward
> 
> On Jul 13, 2021, at 8:08 AM, Hollenbeck, Scott
> <shollenbeck=[email-masked]> wrote:
> > . . .my preference would be for the WG to focus on solutions for
> authoritative name servers serving zones that aren’t delegation-centric.
> 
> This has come up before, and I'm trying to figure out why. If this WG comes
> up with a protocol that any zone operator can choose to implement, why
> differentiate between delegation-centric and anything else? It feels short-
> sighted to look at current zone contents and try to optimize a solution for
> them, instead of just making all DNS extensions optional.

Delegation-centric zones return name server IP addresses that are exposed in subsequent recursive queries. The value proposition of encrypting those addresses in a DNS response has to be weighed against the server resource overhead of adding support for encryption, especially when there are data minimization techniques available that can reduce the amount of information disclosed without putting an operational burden on the authoritative name server. If a solution can be developed that works for all levels of the DNS hierarchy, fine, but I believe there's more value in a solution (or solutions) where the data can't be protected using minimization techniques and there's a greater likelihood of near-term experimentation.

Scott

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 13 Jul 2021 16:18:08 +0000

On Jul 13, 2021, at 8:56 AM, Hollenbeck, Scott <shollenbeck=[email-masked]> wrote:
> If a solution can be developed that works for all levels of the DNS hierarchy, fine

Are you saying that the current WG draft, draft-ietf-dprive-unauth-to-authoritative-03, doesn't work at all levels of the DNS hierarchy? If so, the specifics of that would be important for the WG to work on.

--Paul Hoffman

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 13 Jul 2021 16:32:24 +0000

> From: Paul Hoffman <[email-masked]>
> Sent: Tuesday, July 13, 2021 12:18 PM
> To: Hollenbeck, Scott <[email-masked]>
> Cc: [email-masked]
> On Jul 13, 2021, at 8:56 AM, Hollenbeck, Scott
> Are you saying that the current WG draft, draft-ietf-dprive-unauth-to-
> authoritative-03, doesn't work at all levels of the DNS hierarchy? If so, the
> specifics of that would be important for the WG to work on.

No, I'm responding to Tim's request for input: "We feel like the WG will not be able to make additional progress on any of the proposed solutions until we can reach consensus on whether the solution should be homogeneous from the root down or that the real focus is on SLDs and down."

SLD isn't quite right given that there are second-level domains that act like top-level domains, so I tried to be more precise by using "delegation-centric" instead. The service discovery part of any draft that requires publication of records in the parent could be an issue (as Tim noted), but beyond that I'm not specifically commenting on either of the proposed solution drafts.

Scott

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 14 Jul 2021 19:49:37 +0200

On 13/07/2021 17.56, Hollenbeck, Scott wrote:
> Delegation-centric zones return name server IP addresses that are exposed in subsequent recursive queries. The value proposition of encrypting those addresses in a DNS response has to be weighed against [...]

I think that's a bit too simplified description.  Typically it's the 
QNAME that's privacy sensitive, commonly the label that's necessarily 
sent to TLD operators already.  It's becoming quite common to host DNS 
and content at larger providers, in which case no IP address will be 
that much identifying.*

But I can't see benefit in encryption towards root servers.  And QNAME 
minimization is the first step.  (For root there are various "local" 
approaches, too.)

--Vladimir

* Lots of privacy caveats often remain: the metadata of connections to 
all IPs being sufficiently unique by itself, or encrypted client hello 
missing in TLS.  Still, those sources seem harder to mine than DNS itself.