Subject: [dns-privacy] revisiting ADoT design assumptions

From: Petr Špaček <[email-masked]>
Date: Fri, 12 Nov 2021 18:32:48 +0100

Hello dprive.

I think that Ben Schwartz really hit nail on the head in his DSGLUE 
presentation.

I suggest we _really_ try to get a better idea about design constraints 
first, and work out their implications and protocol from there.

These are the crucial questions (copied and slightly modified from 
https://datatracker.ietf.org/meeting/112/materials/slides-112-dprive-dsglue-01 
slide 5):

* Can we slow down resolution of existing domains?

* Do we care about the latency of A2DoT-enabled domains?

* Do we care about A2DoT under non-A2DoT parents?
   - i.e. protecting label N+1 after label N has leaked
   - Can we require that non-A2DoT parents are signed?

* Can we add new RR types to the glue/parent side?

* Can the child atomically update NS/DS/glue RRSets together in the parent?

* Can we add new digest types to the DS record?

* Can we add DS RRs which do not constitute a valid DNSSEC-validation path?

(The last point was added by me. It equals to "Will RRR ecosystem accept 
DS records which are really not a DNSSEC-validable path?".)

Let us try an experiment:

Could you please fill in yes/no in the following form, so we can quickly 
see if there are totally different opinions or a rare agreement on some 
of the points?

https://docs.google.com/forms/d/e/1FAIpQLSdllOX_cKT8L7bl8_jhxeQPsg1Iqam_rnD6iVVl_R4mnxBN1A/viewform

The form will close on:
Sunday 21th November 2021 23:59 UTC

Maybe it will move us a bit forward if we see some (common) red lines in 
the answers. Or maybe not, we'll see.

P.S. Thank you Ben!

-- 
Petr Špaček

---

From: Puneet Sood <[email-masked]>
Date: Mon, 15 Nov 2021 18:24:17 -0500

Some of the questions need more granularity in the answers.

e.g. "Do we care about the latency of A2DoT-enabled domains?"

We may care on average but with the expectation that the
latency/overhead of the first few queries will be amortized over the
future queries.

On Fri, Nov 12, 2021 at 12:33 PM Petr Špaček <[email-masked]> wrote:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Petr Špaček <[email-masked]>
Date: Tue, 23 Nov 2021 22:13:36 +0100

> the answers. Or maybe not, we'll see.

So far only five people responded, which seems to be pretty low.

To give people more chance to share their thoughts I extend the form 
deadline to Sunday 28th November 2021 23:59 UTC. Please take couple 
minutes to respond!

-- 
Petr Špaček

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 24 Nov 2021 06:38:19 +0100

I agree with Ben’s assumptions and conclusions. 

I believe that, although I myself do not believe the assumed constraints hold in the real world, that there will be others who do.  I believe that proceeding on the assumption that those hypothetical others’ hypothetical objections must be addressed is the correct path.  And I believe that we are not blocked from the unoptimized/simpler path in the mean time.  
    
                -Bill

> On Nov 23, 2021, at 10:14 PM, Petr Špaček <[email-masked]> wrote:
> 
>> I think that Ben Schwartz really hit nail on the head in his DSGLUE presentation.
>> I suggest we _really_ try to get a better idea about design constraints first, and work out their implications and protocol from there.
>> These are the crucial questions (copied and slightly modified from https://datatracker.ietf.org/meeting/112/materials/slides-112-dprive-dsglue-01 slide 5):
>> (The last point was added by me. It equals to "Will RRR ecosystem accept DS records which are really not a DNSSEC-validable path?".)
>> Could you please fill in yes/no in the following form, so we can quickly see if there are totally different opinions or a rare agreement on some of the points?
>> https://docs.google.com/forms/d/e/1FAIpQLSdllOX_cKT8L7bl8_jhxeQPsg1Iqam_rnD6iVVl_R4mnxBN1A/viewform The form will close on:
>> Maybe it will move us a bit forward if we see some (common) red lines in the answers. Or maybe not, we'll see.
> 
> To give people more chance to share their thoughts I extend the form deadline to Sunday 28th November 2021 23:59 UTC. Please take couple minutes to respond!
> 
> -- 
> Petr Špaček
>

---

From: Robert Evans <[email-masked]>
Date: Wed, 24 Nov 2021 13:24:23 -0500

On Wed, Nov 24, 2021 at 12:38 AM Bill Woodcock <[email-masked]> wrote:

> I believe that, although I myself do not believe the assumed constraints
> hold in the real world, that there will be others who do.  I believe that
> proceeding on the assumption that those hypothetical others’ hypothetical
> objections must be addressed is the correct path.  And I believe that we
> are not blocked from the unoptimized/simpler path in the mean time.

What level of interest is there for adopting the unoptimized/slower paths?

If we had a non-parent signal, would any real-world operators adopt it
beyond limited experimentation (accepting extra RTTs and leaky queries)?

If so, would operators prefer to use these signals synchronously (strict
security, slow) or asynchronously (use TLS when ready, fast, but leaky)?

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 24 Nov 2021 20:25:18 +0100

> On Nov 24, 2021, at 7:24 PM, Robert Evans <[email-masked]> wrote:
> 

I, and a number of others, have been trying to move forward with them.  My personal belief is that this is an 80/20 situation, where the 20% of the work to get to the unoptimized state will yield 80% of the benefit.  And for large operators, nearly 100% of the benefit.  Because the larger the DNS operator, the larger the portion of their traffic that goes to (the same unchanging set of) other large operators.  Since those will be long-lived TCP flows to known destinations, all of the optimizations aimed at jump-starting new connections for unknown counterparts won’t apply.  And, honestly, probably won’t be worth the work of implementing, though if the tools automate it well, then that work could hypothetically be minimal.

What would not be a minimal amount of work, though, is moving forward over the objections of people who believe that only 100% solutions are acceptable.  So, having the 100% solution out there in the future to appease them and for them to work on, while the rest of us move forward with the 80% solution, suits me fine.

> If we had a non-parent signal, would any real-world operators adopt it beyond limited experimentation (accepting extra RTTs and leaky queries)?

Seems unlikely.

> If so, would operators prefer to use these signals synchronously (strict security, slow) or asynchronously (use TLS when ready, fast, but leaky)?

I wouldn’t care to hypothesize about the preferences of hypothetical operators that I’m not convinced exist.

                                -Bill

---

From: Paul Wouters <[email-masked]>
Date: Wed, 24 Nov 2021 15:58:53 -0500 (EST)

> I, and a number of others, have been trying to move forward with them.  My personal belief is that this is an 80/20 situation, where the 20% of the work to get to the unoptimized state will yield 8…

Not only that, but the in-baliwick parts are fairly meaningless anyway,
as protecting in-baliwick either adds no real privacy. Either it reveals
a well known large auth server responsibly for huge amounts of domains
that knowing the nameserver won't tell you anything anyway, or it goes
to a tiny nameserver that even if fully encrypted and private, by itself
reveals the target was interested in 1 of a few possible domain names.

And once you are take this into account, just adding a TLSA record at
the nameserver name works fine. As you said, the vast majority of these
can then be long living HTTPS / TLS / QUIC connections.

>> If we had a non-parent signal, would any real-world operators adopt it beyond limited experimentation (accepting extra RTTs and leaky queries)?

A signal on the parent domain seems mostly not adding anything if the
signaling for encrypted transport happens over the nameserver names.

Paul