Subject: [dns-privacy] next steps for draft-opportunistic-adotq

From: Peter van Dijk <[email-masked]>
Date: Mon, 22 Mar 2021 21:26:55 +0100

Hello DPRIVE,

First, a recap of my IETF110 presentation for those who missed it. I
explained that the recent version of our opportunistic/unauthenticated
draft (draft-ietf-dprive-opportunistic-adotq-01) included a rough
skeleton of support for an authenticated use case, because no other
proposal for that was alive at the time. Shortly after, another draft
(draft-rescorla-dprive-adox-latest-00) describing an authenticated
approach appeared. I suggested in my presentation that we take
authentication out of our draft so that the two use cases (being
'unauthenticated' and 'authenticated') can progress side by side.

draft-rescorla-dprive-adox-latest-00 proposes SVCB as a discovery
mechanism instead of our TLSA, and this sounds good to us. The
unauthenticated use case only needs discovery, so SVCB appears to be an
even better fit than TLSA. SVCB also provides more protocol
flexibility.

Our proposal for a way forward:

* We take authentication out of draft-ietf-dprive-opportunistic-adotq
again.
* We give the draft a somewhat more accurate name, as the switch to
SVCB stops us being limited to DoT and DoQ (although I really do wonder
if there is any appetite for DoH on the recursive<>auth path).
* We let the drafts develop side by side, making sure they use similar
wording where appropriate, and don't get in each other's way.

Cheers, Paul&Peter

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 22 Mar 2021 20:59:16 +0000

Hiya,

I think that makes sense with one caveat: I don't interpret
these changes as representing a consensus to not use TLSA - I
think such a decision is still down the road some, after we
have some better ideas as to the practicality or otherwise
of the various approaches one might adopt.

I know none of these are WG drafts yet but I'd be a bit
worried that your changing to use SVCB now might be
intrepreted in that way.

Cheers,
S.

On 22/03/2021 20:26, Peter van Dijk wrote:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Mar 2021 21:10:35 +0000

> worried that your changing to use SVCB now might be

Good point. As we revise this draft, we can put a note in about us needing a signal, and use SCVB as the signal, but the signal might change.

--Paul Hoffman

---

From: Brian Haberman <[email-masked]>
Date: Tue, 23 Mar 2021 10:16:04 -0400

Hey Paul,
     Clarifying question about SVCB...

> Good point. As we revise this draft, we can put a note in about us needing a signal, and use SCVB as the signal, but the signal might change.

Is there an issue with putting SVCB info in the TLD zones? If I
interpret this ICANN document correctly
(https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#exhibitA.1),
there are strict limitations on the info that can be put in the TLD zones.

Regards,
Brian

---

From: Jim Reid <[email-masked]>
Date: Tue, 23 Mar 2021 14:50:00 +0000

> On 23 Mar 2021, at 14:16, Brian Haberman <[email-masked]> wrote:
> 
> Is there an issue with putting SVCB info in the TLD zones?

Yes - for gTLDs. Almost all of them have contracts with ICANN. Adding SVCB records to ccTLDs is easier (in principle) since few (any?) of them have contracts with ICANN. Since those gTLD contracts say “no SVCB records”, registries can’t/shouldn’t add them to their zones.

> If I interpret this ICANN document correctly

Indeed. It is possible to get these contracts to be amended. But it will take endless rounds of meetings, task forces and consultations before an appropriate board resolution could be passed and implemented. Good luck with that...

What would be the point of putting SVCB records in a TLD (or the root)? It seems like a remarkably bad idea to me.

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 23 Mar 2021 15:54:55 +0100

> On Mar 23, 2021, at 3:50 PM, Jim Reid <[email-masked]> wrote:

Yes, I completely agree that the bureaucratic challenge in fixing that idiocy is very, very high.

> What would be the point of putting SVCB records in a TLD (or the root)? It seems like a remarkably bad idea to me.

Why?

There are a million clever and useful things that you could do, if it were possible.  Which are particularly valuable for brand TLDs, for instance.

What arguments exist against it?  Was there some justification, back when that language was put in?  I’ve always assumed it was just existing registries trying to gratuitously jerk new ones around.

                                -Bill

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Mar 2021 10:56:46 -0400 (EDT)

> What would be the point of putting SVCB records in a TLD (or the root)? It seems like a remarkably bad idea to me.

The point of putting them into a TLD would be to be able to build up a
secure private connection to the TLD nameserver, before issuing a target
domain query within the TLD.

There is less need of this in the root, provided the resolver uses
query minimalization.

This is based on my assumption that SVCB records will never be served
by the parent of the domain it is for (something not everyone in the WG
seems to have accepted as operational reality).

Your "remarkably bad idea" needs more qualifications that can be
discussed on technical and societal merit.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Mar 2021 14:59:02 +0000

> there are strict limitations on the info that can be put in the TLD zones.

There are currently such limitations, and only in gTLDs. If the IETF creates a standard that would cause zone owners to want additional record types in their zones, I suspect that the technical and gTLD operator communities will talk to ICANN about changing the contracts.

Said a different way: if this WG wants to have a mechanism for authoritative discovery that involves adding new glue-like records in parent zones, it should not be constrained by current contracts that could be changed in the future.

--Paul Hoffman

---

From: Jim Reid <[email-masked]>
Date: Tue, 23 Mar 2021 15:59:37 +0000

> On 23 Mar 2021, at 14:54, Bill Woodcock <[email-masked]> wrote:
> 

IMO, the IETF shouldn’t get into developing protocols just for the benefit of here today, gone tomorrow brand TLDs.

> What arguments exist against it?  Was there some justification, back when that language was put in?  I’ve always assumed it was just existing registries trying to gratuitously jerk new ones around.

IIUC the ICANN limitations on RRtypes was to stop registries doing stuff like adding A or MX records for names that didn’t have delegations.

---

From: Jim Reid <[email-masked]>
Date: Tue, 23 Mar 2021 16:22:31 +0000

> On 23 Mar 2021, at 14:56, Paul Wouters <[email-masked]> wrote:
> 

These things can be done without needing SVCB records. Though they do make that a little less clunky than trying DoT or DoH to some name in the NS RRset and hoping for the best.

> discussed on technical and societal merit.

Most of the busy TLDs use a mix of DNS providers and so there may not be a uniform provision of DoH and DoT service across all of the TLD’s authoritative servers. [Would busy TLD servers ever do DoT or DoH anyway?] Which I suppose could be argued the other way: for instance don’t send DoT traffic to provider A for $tld because they don’t do DoT.

Using SCVB records to say “send all DoH (say) traffic to $provider” is a vector for all sorts of nasties: DoS, privacy, competition, consolidation/centralisation, robustness, etc. These are things TLDs should try to avoid IMO.

It doesn’t seem right to allow a TLD operator to tell someone what DoH server(s) to use/not use to resolve $tld's names. Would SVCB records let the edge device or end user make informed choices about the privacy (or whatever) policies for those DoH servers? It’s one thing to do that for whatever.com*. IMO it’s something very different for .com as a whole. [*Other TLDs are available.]

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 23 Mar 2021 17:16:17 -0400

> On Mar 23, 2021, at 7:16 AM, Brian Haberman <[email-masked]>
...

> > (
> https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#exhibitA.1
> ),
> There are currently such limitations, and only in gTLDs. If the IETF
> creates a standard that would cause zone owners to want additional record
> types in their zones, I suspect that the technical and gTLD operator
> communities will talk to ICANN about changing the contracts.
>

Paul, are you referring to the linked "Registry Agreement" or is there
another contract document?

The "Registry Agreement" says that "permissible contents" include "NS
records and in-bailiwick glue for DNS servers of registered names in the
TLD".  It seems to me that the IETF defines what constitutes "in-bailiwick
glue".  In my view, if there is an NS record for $NSNAME, and $NSNAME is
in-bailiwick, then any record under $NSNAME that is used by resolvers to
connect to the nameserver in accordance with IETF standards is in-bailiwick
glue, regardless of RR type.

In other words, this agreement seems compatible with our SVCB- and
TLSA-based designs.

Said a different way: if this WG wants to have a mechanism for
> authoritative discovery that involves adding new glue-like records in
> parent zones, it should not be constrained by current contracts that could
> be changed in the future.

I agree; I'm just wondering how sure we are that such a change is needed.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 23 Mar 2021 17:20:21 -0400

On Tue, Mar 23, 2021 at 12:23 PM Jim Reid <[email-masked]> wrote:

> It doesn’t seem right to allow a TLD operator to tell someone what DoH
> server(s) to use/not use to resolve $tld's names.

I think there's a miscommunication here.  The proposals here are about
how a TLD operator can tell a **recursive resolver** what encrypted DNS
server to use, exactly like an NS record.  This is not suggesting any
change to stub resolver behavior.

---

From: Jim Reid <[email-masked]>
Date: Tue, 23 Mar 2021 21:22:15 +0000

> On 23 Mar 2021, at 21:20, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> I think there's a miscommunication here.  The proposals here are about how a TLD operator can tell a **recursive resolver** what encrypted DNS server to use, exactly like an NS record.  This is not suggesting any change to stub resolver behavior.

Ben, I was referring to recursive resolver behaviour, not stubs.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Mar 2021 21:29:57 +0000

On Mar 23, 2021, at 2:16 PM, Ben Schwartz <[email-masked]> wrote:
> In my view, if ...

Proposal: we don't pretend to be contract lawyers here. 

If the WG makes a technical change that would affect contracts (not just ICANN contracts), the contracted parties can then discuss those among themselves.

--Paul Hoffman

---

From: Rob Sayre <[email-masked]>
Date: Tue, 23 Mar 2021 15:13:31 -0700

> Proposal: we don't pretend to be contract lawyers here.

Heavy +1. It's always easy to fall into this mode, and it's a known IETF
antipattern.

thanks,
Rob

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Mar 2021 18:32:24 -0400 (EDT)

> Ben, I was referring to recursive resolver behaviour, not stubs.

The authoritative server expresses where to find its nameservers via its parent.

This is not different. I guess you feel this is different because instead
of publishing NS and A records about itself, it can now point to something
that is not a NS or A record. But this is not really different if the
parent can add NS/A records anyway.

eg an SVCB record that states "do DoT at 1.2.3.4" is the same
as adding a NS record like:

example.com.		IN	NS	ns1.example.com.
example.com.		IN	NS	xn--dot.example.com.
ns1.example.com		IN	A	1.2.3.5
xn--dot.example.com	IN	A	1.2.3.4

Except that now legacy servers also contact the DoT server, where as
with SVCB or any other kind of known _prefix, the DoT server does not
have to also be a regular nameserver.

So what is it that you are exactly objecting to? The syntax or the capability?

Paul

---

From: Jim Reid <[email-masked]>
Date: Tue, 23 Mar 2021 22:48:35 +0000

> On 23 Mar 2021, at 22:32, Paul Wouters <[email-masked]> wrote:
> 

The capability - mostly. TLDs should not be publishing SVCB records for the reasons I outlined before.

I’m not too keen on using SVCB records apart from stubs finding resolvers on their local network. It’s OK for me to publish SVCB records in rfc1035.com for anyone who has the misfortune to be one of my local users and needs to find an encrypted resolver. IMO it’s not OK to do that in .com (say) for everthing on the planet that needs to lookup a .com domain name.

This is all somewhat moot because I very much doubt any busy TLD will ever turn on DoT or DoH on their authoritative name servers.

---

From: Rob Sayre <[email-masked]>
Date: Tue, 23 Mar 2021 15:55:57 -0700

On Tue, Mar 23, 2021 at 3:49 PM Jim Reid <[email-masked]> wrote:

>
> This is all somewhat moot because I very much doubt any busy TLD will ever
> turn on DoT or DoH on their authoritative name servers.
>

That isn't clear to me. Is there a good measurement on traffic to these?
Last time I tried to look, the query volume seemed lower than Twitter's,
let alone Google, Facebook, etc.

thanks,
Rob

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Mar 2021 19:01:19 -0400

> The capability - mostly. TLDs should not be publishing SVCB records for the reasons I outlined before.

What you outlined is not clear.

> I’m not too keen on using SVCB records apart from stubs finding resolvers on their local network. It’s OK for me to publish SVCB records in rfc1035.com for anyone who has the misfortune to be one o…

I think you are misinterpreting the draft. The goal is to advertise DoT servers ONLY for yourself, not for your children or parent.

There might be some confusion because the draft editors mistakenly believe they can get child SVCB records published at the server, like DS records. I’ve already tried to convince them that is not going to happen.

> This is all somewhat moot because I very much doubt any busy TLD will ever turn on DoT or DoH on their authoritative name servers.

SVCB allows them to put those servers in as separate infrastructure that would not affect regular nameserver operation. There is discussion about conveying status (testing, production) within the SVCB record.

Paul

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 24 Mar 2021 11:50:04 +0200

On Tue, Mar 23, 2021 at 02:50:00PM +0000, Jim Reid wrote:
> Yes - for gTLDs. Almost all of them have contracts with ICANN. Adding
> SVCB records to ccTLDs is easier (in principle) since few (any?) of
> them have contracts with ICANN. Since those gTLD contracts say “no
> SVCB records”, registries can’t/shouldn’t add them to their zones.

I took a look how many gTLDs have in-zone nameservers:

Found total of 1503 TLDs:
- 779 TLDs have in-bailiwick nameserver(s).
- The remaining 724 have all their nameservers in another TLD.

Of the 779 TLDs that have in-bailiwick nameserver(s):
- 58 TLDs have in-zone nameserver(s).
- The remaining 721 have all their nameservers in other zone(s).

Of the 58 TLDs that have in-zone nameserver(s):
- 3 are gTLDs.
- The remaining 55 are ccTLDs.

The 3 gTLDs with in-zone nameservers are:
- brussels.
- tel.
- vlaanderen.

So looks like 1500 out of 1503 TLDs could add new rrtypes to their
nsname nodes. And the remaining 3 could do so after spliting out the
subzone with their nameservers into full zone.

Notes:

- Some TLDs have both in-bailiwick and out-bailiwick nameservers. E.g.,
  ad.
- All 2-character names are assumed to be ccTLD, everything else is
  assumed to be gTLD.
- None of the gTLDs with in-zone nameservers have any out-zone
  nameservers.
- Some ccTLDs have both in-zone and out-zone nameservers. E.g., at.
- None of the gTLDs with in-zone nameservers have any nameservers
  directly under apex.
- There are some ccTLDs that have put their nameservers directly under
  their apex. E.g., fi.

-Ilari

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 24 Mar 2021 14:34:28 +0100

On Mar 23, 2021, at 18:48, Jim Reid <[email-masked]> wrote:
> TLDs should not be publishing SVCB records for the reasons I outlined before.

I’m still looking for those reasons.  Could you enumerate them again?

> I very much doubt any busy TLD will ever turn on DoT or DoH on their authoritative name servers.

I’ve got a few hundred that say otherwise.

                                -Bill

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Mar 2021 13:54:16 +0000

> On 24 Mar 2021, at 13:34, Bill Woodcock <[email-masked]> wrote:
> 

No. You can re-read my earlier mail which enumerated those reasons. If you want to discuss specifics, I’m happy to do so. Though the issue of SVCB records in TLDs is somewhat orthogonal to draft-opportunistic-adotq - as Paul Wouters pointed out. Perhaps that should be discussed off-list.

> I’ve got a few hundred that say otherwise.

That’s fine Bill. However I think we’re using different definitions of busy.

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 24 Mar 2021 15:10:41 +0100

> On Mar 24, 2021, at 2:54 PM, Jim Reid <[email-masked]> wrote:

How many mqps are necessary to have a voice in your vision of multistakeholderism?

Or, viewed from the other end of the spectrum, are you suggesting that only the two or three largest TLDs out of two thousand, count?

                                -Bill

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Mar 2021 14:56:01 +0000

> On 24 Mar 2021, at 14:10, Bill Woodcock <[email-masked]> wrote:
> 

I don’t know.

I think/hope we have the same vision of multistakeholderism. If not, that’s a conversation for another time and place.

> Or, viewed from the other end of the spectrum, are you suggesting that only the two or three largest TLDs out of two thousand, count?

No, of course not. Any TLD or authoritiev server is welcome to do whatever it wants here. Even if I think it’s a bad idea. Which could very well be an incentive for others to deploy.

What I am saying is this WG needs to think more about the impacts* of Do[TH] on busy authoritative servers (not just TLDs). And maybe for busy recursive servers too. Some of us were talking about that just over an hour ago in the RIPE DNS WG:

https://www.ripe.net/participate/ripe/wg/active-wg/dns/remote-sessions/2021-03-24-ripe-dns-wg-hollenbeck-balanced-dns-information-protection-strategy.pdf

AFAICT the WG hasn’t yet considered any of the risk analysis issues identified in Scott’s presentation.

* Those impacts BTW go beyond query rates or TLS session management.

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 24 Mar 2021 16:01:14 +0100

> On Mar 24, 2021, at 3:56 PM, Jim Reid <[email-masked]> wrote:
> What I am saying is this WG needs to think more about the impacts* of Do[TH] on busy authoritative servers (not just TLDs).

I assume folks have read this:

    https://vaibhavbajpai.com/documents/papers/proceedings/dot-pam-2021.pdf

That’s a completely legit concern, but each zone can advertise availability of encrypted connections as much or as little as it wants, and is free to prioritize allocation of encrypted connections to whomever it wants.  So I wouldn’t call it an “impact” so much as a “cost to be managed."

                                -Bill

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Mar 2021 17:24:01 -0700

On Wed, Mar 24, 2021 at 7:56 AM Jim Reid <[email-masked]> wrote:

> I think/hope we have the same vision of multistakeholderism. If not,
> that’s a conversation for another time and place.
>
> > Or, viewed from the other end of the spectrum, are you suggesting that
> only the two or three largest TLDs out of two thousand, count?
>
> No, of course not. Any TLD or authoritiev server is welcome to do whatever
> it wants here. Even if I think it’s a bad idea. Which could very well be an
> incentive for others to deploy.
>
> What I am saying is this WG needs to think more about the impacts* of
> Do[TH] on busy authoritative servers (not just TLDs). And maybe for busy
> recursive servers too. Some of us were talking about that just over an hour
> ago in the RIPE DNS WG:
>
>

Right. I've read this and I think it's interesting but not really
dispositive. It seems to me that there are two arguments here:

- The combination of QMIN and aggregation/caching around the recursive
  decreases the need for TLS to the root and the TLD

- There are operational risks to running TLS on the root and TLD
  servers

WRT the first point, I don't think QMIN helps as much as you might
like for two reasons:

1. In a very large number of cases, it's the SLD which is sensitive.
   This means that QMIN at the TLD doesn't really help at all.
   And by extension, because you need to protect the NS record
   for the TLD (and they're not DNSSEC signed at the parent),
   not having TLS to the root means that you don't adequately
   protect the TLS connection to the TLD server either.

2. It's true that caching by the recursive helps some -- especially
   for large resolvers -- but there is still some information
   leakage if the cache is cold and you can observe both sides.
   Moreover, this just seems like an argument against ADoX entirely,
   because it applies as much to the connection to the SLD server.
   And given that ADoX is a charter item, it seems like there is a
   presumption that we should be working on this.

WRT the operational risk (slide 3), it's likely true that it's
somewhat harder to run a DoX server than a Do53 server. However, given
that we have plenty of worked examples of TLS servers of comparable if
not greater scale being operated with high reliability (e.g., Google,
Fastly, Cloudflare, etc.), I think there's pretty strong evidence that
this is an operational issue that can be addressed.

Of course, the IETF can't make the TLD servers run ADoX, but as
long as some TLDs are willing to, it seems odd not to specify it,
especially as the mechanisms are mostly the same at every level
of the hierarchy.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 27 Mar 2021 02:02:14 +0000

Hiya,

Not asking anyone in particular but...

On 27/03/2021 00:24, Eric Rescorla wrote:
> somewhat harder to run a DoX server than a Do53 server. However,
> given that we have plenty of worked examples of TLS servers of
> comparable if not greater scale being operated with high reliability
> (e.g., Google, Fastly, Cloudflare, etc.), I think there's pretty
> strong evidence that this is an operational issue that can be
> addressed.

That's been said a number of times, and I think has a
fairly clear ring of truth to it, but yet it somehow doesn't
seem to sway those who operate larger scale Do53 services
today.

Can anyone help me understand that?

I could understand if the justifications were down to
stability or cost, either of which could be valid
engineering reasons why someone might prefer the status-quo,
but I don't think I've seen the argument made explicit in
either of those ways.

I don't have first-hand knowledge of this, so it'd
help me at least if it the reasons why DoH or DoT are
hard for (especially the likes of .com/.net) could be
further clarified.

Thanks,
S.

---

From: Rob Sayre <[email-masked]>
Date: Fri, 26 Mar 2021 19:24:22 -0700

> Can anyone help me understand that?

I can't help, but I don't understand it either.

If someone were to come back with data on cost or stability, that might be
helpful.

thanks,
Rob

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 29 Mar 2021 17:02:33 +0000

> -----Original Message-----
> From: dns-privacy <[email-masked]> On Behalf Of Stephen
> Farrell
> Sent: Friday, March 26, 2021 10:02 PM
> To: Eric Rescorla <[email-masked]>; Jim Reid <[email-masked]>
> Cc: DNS Privacy Working Group <[email-masked]>; Bill Woodcock
> <[email-masked]>
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] next steps for draft-
> opportunistic-adotq
>
>
> Hiya,
>
> That's been said a number of times, and I think has a fairly clear ring of truth
> to it, but yet it somehow doesn't seem to sway those who operate larger
> scale Do53 services today.
>
> I could understand if the justifications were down to stability or cost, either
> of which could be valid engineering reasons why someone might prefer the
> status-quo, but I don't think I've seen the argument made explicit in either of
> those ways.
>
> I don't have first-hand knowledge of this, so it'd help me at least if it the
> reasons why DoH or DoT are hard for (especially the likes of .com/.net) could
> be further clarified.

[SAH] I'm working on a more detailed response, but in the meantime it might help to read this expired Internet-Draft:

https://www.ietf.org/archive/id/draft-hal-adot-operational-considerations-02.txt

Scott