Subject: [dns-privacy] Common Features for Encrypted Recursive to Authoritative DNS

From: Peter van Dijk <[email-masked]>
Date: Sun, 02 May 2021 18:54:55 +0200

Hello DPRIVE!

in the last two draft revisions of our protocol for unauthenticated
encryption from resolvers to authoritatives, we adopted the SVCB
discovery mechanism from draft-rescorla-dprive-adox-latest-00. This
means that the two documents overlap somewhat, and there would be
effort needed to keep the mechanisms in sync.

To avoid that problem, instead we present here a separate document that
contains the parts that the two protocols have in common. Our draft is
adopted; we understand the authors of the authenticated draft intend to
ask for adoption soon, as well. If the WG adopts this separate
document, we will not have to keep the discovery bits in sync between
the two, and we can hammer out the details of discovery once, in a
single place.

We imagine this would be much more efficient.

- Paul & Peter

-------- Forwarded Message --------
From: [email-masked]
To: Paul Hoffman <[email-masked]>, Peter van Dijk <
[email-masked]>
Subject: [EXT] New Version Notification for draft-pp-dprive-common-
features-00.txt
Date: Sun, 02 May 2021 09:51:09 -0700

A new version of I-D, draft-pp-dprive-common-features-00.txt
has been successfully submitted by Peter van Dijk and posted to the
IETF repository.

Name:		draft-pp-dprive-common-features
Revision:	00
Title:		Common Features for Encrypted Recursive to Authoritative DNS
Document date:	2021-05-02
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/archive/id/draft-pp-dprive-common-features-00.txt
Status:         https://datatracker.ietf.org/doc/draft-pp-dprive-common-features/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-pp-dprive-common-features
Htmlized:       https://tools.ietf.org/html/draft-pp-dprive-common-features-00

Abstract:
   Encryption between recursive and authoritative DNS servers is
   currently being defined in two modes: unauthenticated and fully-
   authenticated.  These two modes have some features in common, and
   this document defines those common features so that the documents
   defining the modes do not need to point to each other.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 3 May 2021 14:06:34 -0700

Thanks for this draft; I think it's clear and could be a helpful
introduction.

>    If the cache has no positive or negative answers for any DNS SVCB
   record for any of a zone's authoritative servers, the resolver needs
   to send queries for the DNS SVCB records for some or all of the
   zone's authoritative servers.

I think it would be worth rephrasing the words "needs to" here.  To me,
this sounds like a normative requirement to perform these queries, but I
suspect that's not what you mean.

>    Because some authoritative servers or middleboxes are misconfigured,
   requests for unknown RRtypes might be ignored by them.  Resolvers
   should be ready to deal with timeouts or other bad responses to their
   SVCB queries.

This sounds a bit pessimistic.  Ralf Weber recently published some figures
showing a ~0.03% failure rate.  For security (in the authenticated case),
any mitigations here are very delicate, and I'm a bit concerned about the
brief treatment here.  (The SVCB draft has an extensive discussion:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-3.1
.)

>    DNS SVCB records act as advisory information for resolvers about the
   encrypted protocols that are supported.  They can be thought of as
   similar to NS records on the parent side of a zone cut: advisory
   enough to act on, but not authoritative.  Given this, authoritative
   servers that know the DNS SCVB records associated with NS records for
   any child zones MAY include those DNS SCVB records in the Additional
   section of responses to queries to a parent authoritative server.

This sounds like a restatement of the definition of "glue".  Can we simply
declare that these records are "glue"?

--Ben

On Sun, May 2, 2021 at 9:55 AM Peter van Dijk <[email-masked]>
wrote:

> URL:
> https://www.ietf.org/archive/id/draft-pp-dprive-common-features-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-pp-dprive-common-features/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-pp-dprive-common-features
> Htmlized:
> https://tools.ietf.org/html/draft-pp-dprive-common-features-00
>
>
> Abstract:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 4 May 2021 12:28:52 +0000

From: dns-privacy <[email-masked]> On Behalf Of Ben Schwartz
Sent: Monday, May 3, 2021 5:07 PM
To: Peter van Dijk <[email-masked]>
Cc: DNS Privacy Working Group <[email-masked]>
Subject: [EXTERNAL] Re: [dns-privacy] Common Features for Encrypted Recursive to Authoritative DNS

Thanks for this draft; I think it's clear and could be a helpful introduction.

I think it would be worth rephrasing the words "needs to" here.  To me, this sounds like a normative requirement to perform these queries, but I suspect that's not what you mean.

This sounds a bit pessimistic.  Ralf Weber recently published some figures showing a ~0.03% failure rate.  For security (in the authenticated case), any mitigations here are very delicate, and I'm a bit concerned about the brief treatment here.  (The SVCB draft has an extensive discussion: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-3.1<https://secure-web.cisco.com/1KnxioJRTsf2uU1VW48qiLA_fHonJvyIlr7lqXBxF6-KQR8Euua8L4CgmpRZkuoe3cS_yTHaQPg9FD3nkj_RHY-7yCOcDuoR0vc6wkDa4uosV1tNCYOe3JcJGQw4KVsb_RRkzvTdQzxZbbHaeKPNC-UoXqfqMnCJOBub4XxG4JGbTo9MgdOEOKuLYS5gLGHiTqG9dVKWxkkqoBQ-9y8O0rUmFU45Xz9IAIBDvgTzxMUs3l2voDFu2pMpIcyVBnHF2/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dnsop-svcb-https%23section-3.1>.)

This sounds like a restatement of the definition of "glue".  Can we simply declare that these records are "glue"?

[SAH] …and does this imply that we need to extend EPP to populate these records?

Scott

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 7 May 2021 03:20:55 +0000

> I think it would be worth rephrasing the words "needs to" here.  To me, this sounds like a normative requirement to perform these queries, but I suspect that's not what you mean.

Good catch. In retrospect, this topic is actually not common between the two use cases, so we'll take it out of the "common" document and expect each protocol document to deal with what to do if the cache has no positive or negative answers for any DNS SVCB record for any of a zone's authoritative servers.

> This sounds a bit pessimistic.  Ralf Weber recently published some figures showing a ~0.03% failure rate.  For security (in the authenticated case), any mitigations here are very delicate, and I'm a bit concerned about the brief treatment here.  (The SVCB draft has an extensive discussion: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-3.1.)

This was a leftover from earlier drafts, and you are right that this is adequately covered in the SVCB draft itself. We'll remove it.

> This sounds like a restatement of the definition of "glue".  Can we simply declare that these records are "glue"?

We do not get to redefine a 30-year-old concept just because we have a new shiny thang. We tried to say "treat similar to glue", and that wording could maybe be improved.

> [SAH] …and does this imply that we need to extend EPP to populate these records?

Wrong working group, Scott. :-) My personal opinion is that there are mechanisms defined by DNSOP for child-to-parent communication that would probably work much better than yet another REGEXT WG document.

--Paul Hoffman

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 7 May 2021 12:03:51 +0000

> -----Original Message-----
> From: dns-privacy <[email-masked]> On Behalf Of Paul
> Hoffman
> Sent: Thursday, May 6, 2021 11:21 PM
> To: Ben Schwartz <bemasc=[email-masked]>
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] Common Features for Encrypted
> Recursive to Authoritative DNS
> 
> On May 3, 2021, at 2:06 PM, Ben Schwartz
> <bemasc=[email-masked]> wrote:
> Good catch. In retrospect, this topic is actually not common between the two
> use cases, so we'll take it out of the "common" document and expect each
> protocol document to deal with what to do if the cache has no positive or
> negative answers for any DNS SVCB record for any of a zone's authoritative
> servers.
> 
> showing a ~0.03% failure rate.  For security (in the authenticated case), any
> mitigations here are very delicate, and I'm a bit concerned about the brief
> treatment here.  (The SVCB draft has an extensive discussion:
> https://secure-web.cisco.com/15G9BV5N6Ayfy89k3tshwvv0Hj-
> zjPlc6kJw1CJqi6AgP3dFYb3rxKKH8mi4aa9YeME86836s0ekEY1nApKWIFnccrAv
> IZEd6FCFj83J5RDOpPrUmu05qr8Q9AdovzfGTj7OCaECH7_kA7XdSfC_LW1Ldh
> T68yxlKSrCBbonEKberR2w0XZ3FpPvQCuROK63spcmNV-
> n3kzVu8JE663OkGbqoSrNiKazCnaj6b6to34xrxtNvrtC5Gk2vycrcfE4S-
> IKD5bXC2IYoYt563cbwaibm-
> zEtpU_H5WIMSebB9l0/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtm
> l%2Fdraft-ietf-dnsop-svcb-https%23section-3.1.)
> 
> This was a leftover from earlier drafts, and you are right that this is
> adequately covered in the SVCB draft itself. We'll remove it.
> 
> We do not get to redefine a 30-year-old concept just because we have a new
> shiny thang. We tried to say "treat similar to glue", and that wording could
> maybe be improved.
> 
> On May 4, 2021, at 5:28 AM, Hollenbeck, Scott
> <shollenbeck=[email-masked]> wrote:
> >
> Wrong working group, Scott. :-) My personal opinion is that there are
> mechanisms defined by DNSOP for child-to-parent communication that
> would probably work much better than yet another REGEXT WG document.

[SAH] Asking the question here doesn't make this the wrong venue. If these records need to be treated like glue records, publication needs to be addressed _somewhere_. Once a preference is established, the specification work can be handed off to the appropriate WG.

Scott