Subject: [dns-privacy] please adopt draft-dkgjsal-dprive-unilateral-probing as a WG work item Re: New Version Notification for draft-dkgjsal-dprive-unilateral-probing-02.txt

From: Peter van Dijk <[email-masked]>
Date: Thu, 03 Feb 2022 11:03:35 +0100

Daniel, Joey,

On Thu, 2022-01-27 at 16:43 -0500, Daniel Kahn Gillmor wrote:
> --------
> ### Substantive changes from -01 to -02
> 
> - Clarify that deployment to a pool does not need to be strictly simultaneous
> - Explain why authoritatives need to serve the same records regardless of SNI
> - Defer to external, protocol-specific references for resource management
> - Clarify that probed connections must not fail due to authentication failure
> --------

Thank you for this, this document is evolving very nicely.

Speaking only for myself: some of the parts still seem too prescriptive
to me (but I know I haven't been clear on what parts!). Examples: 4.3.1
seems too focused on some specific load balancer implementations, and
causes a terrible combinatorial state explosion. 4.5 could perhaps use
some words along the lines of "we describe an algorithm here; you could
use another algorithm if it fits your implementation better, as long as
it has similar outcomes". I do like that it mentions happy eyeballs
without prescribing them.

Speaking for both myself and Paul Hoffman: we are happier with your
document than with our currently adopted work. We strongly suggest that
the WG adopts unilateral-probing so we can work out what it would take
to get some implementation work going.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 03 Feb 2022 12:59:52 -0500

Hi Peter, DPRIVE folks--

On Thu 2022-02-03 11:03:35 +0100, Peter van Dijk wrote:
> causes a terrible combinatorial state explosion.

§4.3.1 ("Separate State for Each of the Recursive Resolver's Own IP
Addresses") was added specifically in response to concerns raised by
load balancer operators, in coordination with §3.1 (guidance to the pool
operators themselves), with a goal of convincing anyone interested that
the system isn't going to be overwhelming as long as everyone involved
sticks to a few simple and plausible guidelines.

I don't think that there is a combinatorial state explosion here --
every system that queries from a different outbound address just keeps
its own copy of its state, no?  This seems no worse than having to track
established connections based on which local IP address they are
attached to, which is pretty standard.

It's possible that some other set of choices can offer equally
unthreatening system analysis, but if we're proposing an alternative, we
should write it down explicitly so that people can identify potential
problems.  Being able to reason about the system as a whole is an
important part of this kind of description.

> 4.5 could perhaps use some words along the lines of "we describe an
> algorithm here; you could use another algorithm if it fits your
> implementation better, as long as it has similar outcomes". I do like
> that it mentions happy eyeballs without prescribing them.

Thanks, this is useful feedback too.

I think the goal of the draft is to concretely describe a specific
algorithm so that implementers don't have to invent one from scratch.

I'm happy with the terminology you use above, with the slight caveat that
we'd want to be pretty clear about what "similar outcomes" means.  In
particular, i want "similar outcomes" to encompass not only "did the end
user get the right data?" and "did the proportion of
recursive-to-authoritative queries that was served under encrypted
transport actually improve?" but also "does the alternate algorithm
discourage authoritative servers from deploying secure transport?" and
"will you be able to integrate signalling mechanisms for stronger
connections when they become available"?

One reason to be concerned about divergence from the described approach
is if it interacts poorly with someone else's *different* divergence
from approaches described in the draft, for example the guidance around
operating and dealing with pools that we're discussing above ☺

> to get some implementation work going.

Thanks for the vote of confidence!  I know that Joey and i would both be
fine with WG adoption of this draft, and I think we'd both be game to
volunteer to continue on as editors were the WG to take over authorship.
We'd also be fine with having an additional editor or two on the draft
if someone is interested in stepping up and game to share the workload.

Joey, please correct me if i'm misrepresenting you on any of this!

   --dkg

---

From: Joey Salazar <[email-masked]>
Date: Mon, 7 Feb 2022 15:51:40 +0100

Hi dkg, Peter, dprive,

> sticks to a few simple and plausible guidelines.
+1, other perspectives can (and some already have) be(en) included. I think
that if the text starts getting too specific or unclear for different
implementations, then a generalization could be kept in the main text and
implementation-specific guidelines could populate the Appendix, but it has
indeed been a goal of us to cover enough scenarios as to dissuade
hesitation to adopt/implement.

> Thanks, this is useful feedback too.
Very!

> connections when they become available"?
+1, we could then possibly add a section covering these "similar outcomes"
at some point

> if someone is interested in stepping up and game to share the workload.
Thank you for the support! I'm also fully onboard with the draft going for
adoption and with all subsequent WG decisions, remaining available in any
capacity as needed : )

Thank you all,
--
Joey

---

From: Peter van Dijk <[email-masked]>
Date: Thu, 10 Feb 2022 18:56:05 +0100

> sticks to a few simple and plausible guidelines.

Right, that makes sense!

> its own copy of its state, no?

If they are separate systems, yes!

Some resolvers (such as Unbound) can use a whole /64 of v6 (or a /24 of
v4, if you happen to have one lying around) as extra entropy. In those
cases, it would really be a lot of extra state.

> important part of this kind of description.

Agreed.

> operating and dealing with pools that we're discussing above ☺

Yes, that seems fair, and also a hard puzzle.

Kind regards,