Subject: [Add] The ADD WG has placed draft-schwartz-svcb-dns in state "Call For Adoption By WG Issued"

From: IETF Secretariat <[email-masked]>
Date: Tue, 14 Sep 2021 16:57:32 -0700

The ADD WG has placed draft-schwartz-svcb-dns in state
Call For Adoption By WG Issued (entered by Glenn Deen)

The document is available at
https://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/

Comment:
A Call for WG adoption is being made for DRAFT-SCHWARTZ-SVCD-DNS by the ADD
Chairs.

  ADD currently has 2 WG drafts which have this draft as a dependency:

   -  draft-ietf-add-ddr (Discovery of Designated Resolvers)
   - draft-ietf-add-dnr (DHCP and Router Advertisement Options for the
   Discovery of Network-designated Resolvers)

Please send your comments on this WG Adoption call to the ADD list
([email-masked]).

The WG adoption call will be open for 2 weeks until September 29th

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 14 Sep 2021 17:32:27 -0700

I support adoption—this draft is an important normative dependency for our drafts, and provides a good foundation.

Best,
Tommy

> On Sep 14, 2021, at 4:57 PM, IETF Secretariat <[email-masked]> wrote:
> 
> 
> -- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 15 Sep 2021 00:41:43 +0000

I support adoption. This is a stable platform for current and future documents (besides DDR and DNR) which need to describe DNS service capabilities.

Thanks,
Tommy J

> -----Original Message-----
> From: Add <[email-masked]> On Behalf Of IETF Secretariat
> Sent: Tuesday, September 14, 2021 4:58 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [EXTERNAL] [Add] The ADD WG has placed draft-schwartz-svcb-dns in
> state "Call For Adoption By WG Issued"
> 
> 
> The ADD WG has placed draft-schwartz-svcb-dns in state Call For Adoption By
> WG Issued (entered by Glenn Deen)
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatra
> cker.ietf.org%2Fdoc%2Fdraft-schwartz-svcb-
> dns%2F&amp;data=04%7C01%7CJensen.Thomas%40microsoft.com%7C5819bc
> ab2332428b548808d977db73f5%7C72f988bf86f141af91ab2d7cd011db47%7C
> 1%7C0%7C637672606738689225%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> amp;sdata=OzntABHJ5dv4K7LG7ZlEeG7RuOAOqgrWWTXqZNJ5oU4%3D&amp;r
> eserved=0
> 
> Comment:
> A Call for WG adoption is being made for DRAFT-SCHWARTZ-SVCD-DNS by the
> ADD Chairs.
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=04%7C01%7CJensen.Thomas
> %40microsoft.com%7C5819bcab2332428b548808d977db73f5%7C72f988bf86
> f141af91ab2d7cd011db47%7C1%7C0%7C637672606738689225%7CUnknown
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> iLCJXVCI6Mn0%3D%7C1000&amp;sdata=SrVRlTN4EE2jevuPxl%2BZ6%2B%2Bxv
> qjD6%2BBSYFCSYFl%2F6Ek%3D&amp;reserved=0

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 15 Sep 2021 00:45:19 +0000

(Removing my Reply All mistakes before anyone also replies to the secretariat)

> From: Add <[email-masked]> On Behalf Of Tommy Jensen
> Sent: Tuesday, September 14, 2021 5:42 PM
> To: IETF Secretariat <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Add] [EXTERNAL] The ADD WG has placed draft-schwartz-svcb-dns
> in state "Call For Adoption By WG Issued"
> 
> I support adoption. This is a stable platform for current and future documents
> (besides DDR and DNR) which need to describe DNS service capabilities.
> 
> Thanks,
> Tommy J
> 
> > Subject: [EXTERNAL] [Add] The ADD WG has placed
> > draft-schwartz-svcb-dns in state "Call For Adoption By WG Issued"
> >
> >
> > The ADD WG has placed draft-schwartz-svcb-dns in state Call For
> > Adoption By WG Issued (entered by Glenn Deen)
> >
> > A Call for WG adoption is being made for DRAFT-SCHWARTZ-SVCD-DNS by
> > the ADD Chairs.
> >
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> ie%2F&amp;data=04%7C01%7CJensen.Thomas%40microsoft.com%7C2467315
> cff8c4
> >
> bf4e3bf08d977e1a446%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
> 7C63767
> >
> 2633287135366%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2lu
> >
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=6zOZXu5VYEYnI
> uz%2F
> > ZkFbzqCcsmX9bz2%2BTHphipenaIg%3D&amp;reserved=0
> >
> %40microsoft.com%7C2467315cff8c4bf4e3bf08d977e1a446%7C72f988bf86f1
> 41af91ab2d7cd011db47%7C1%7C0%7C637672633287145322%7CUnknown%
> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C1000&amp;sdata=lnRO9XHX1ikGwW4ZuEfEsqxpmj4dNGP
> WSFeL%2BjTfSvQ%3D&amp;reserved=0

---

From: tirumal reddy <[email-masked]>
Date: Wed, 15 Sep 2021 09:15:26 +0530

The draft is in a good condition and I support adoption of the draft. I
will provide a more substantial review as the document progresses.

Cheers,

-Tiru

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Sep 2021 15:31:25 -0400 (EDT)

> A Call for WG adoption is being made for DRAFT-SCHWARTZ-SVCD-DNS by the ADD

I think I missed previous discussion about this. I'm a little surprised
at the call for adoption, so apologies if this reply comes late.

I believe this draft is not the best idea. It basically copies a lot of
"unsigned" data to turn it into a "signed" copy. The more obvious
approach would be to just provide a signature over the unsiged data in
the new DS variant record, which would reduce a lot of complexity.

A parent that wishes harm, eg wants to modify the unsigned data it has,
would be caught either way. A non-parent (forwarder in the middle)
should have no chance to forge anything to begin with because it should
require the child version of the NS RRset anyway, and thus already can
authenticate by checking existing DNSSEC signatures.

I am also not sure about the encodings here. It is not wire format and
it is mostly not presentation format. Why introduce a new format?

Section 4 contains a special DS record to disable DANE? I am not sure I
understand how and more importantly, where this works. If this is about
the child zone, then perhaps we should not give the parent zone the
power via DS records to make such statements about the child zone. Eg a
nation state could globally disable DANE by adding these special DS
records for all its delegations. It would be much better to encode some
SVCB style record into DS and have a child CDS record that can be used
to confirm the child's intent.

Section 5 says to not use DSGLUE without DNSSEC, but one has to wonder
what the gains are. If it can be used to find a more secure transport,
even without dnssec, why not? As the alternative is to not use the
record and use plain old insecure DNS with no known trust anchors
anyway?

It seems the IETF processes around encrypted DNS keep walking around
the elephant in the room. A few extra RTTs for privacy that focuses
on unrealistic privacy gains on in-baliwick nameservers TLS connection.

If you want real privacy gains from encrypted DNS, you have no choice
but to group yourself onto large DNS hosters anyway, and then the fact
that your reveal to talk to the large hosters DNS nameserver is a moot
point. This is all way too much complexity for no real operational
benefit.

Paul

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 15 Sep 2021 15:33:50 -0400

Hi Paul,

We should definitely talk about DSGLUE, but this call for adoption is for
https://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/

--Ben

On Wed, Sep 15, 2021 at 3:31 PM Paul Wouters <[email-masked]> wrote:

> ADD

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Sep 2021 15:35:48 -0400 (EDT)

On Wed, 15 Sep 2021, Ben Schwartz wrote:

> To: Paul Wouters <[email-masked]>
> Subject: Re: [Add] The ADD WG has placed draft-schwartz-svcb-dns in state
>     "Call For Adoption By WG Issued"
> 
> Hi Paul,
> We should definitely talk about DSGLUE, but this call for adoption is
> for https://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/

Ahh sorry, my tabs and emails got fixed up.

I support adoption of draft-schwartz-svcb-dns

Paul

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 15 Sep 2021 17:57:55 -0400

Hi

I've read this over and I support adoption of draft-schwartz-svcb-dns

tim

---

From: Daniel Migault <[email-masked]>
Date: Thu, 16 Sep 2021 07:38:01 -0400

As far as I remember there are some aspects - such as the way alternate
resolvers - are handled that might need some additional discussions. but I
am happy to refresh my readings and move that document forward. I support
the adoption of the document.
Yours,
Daniel

-- 
Daniel Migault
Ericsson

---

From: Peter van Dijk <[email-masked]>
Date: Tue, 21 Sep 2021 20:13:35 +0200

> A Call for WG adoption is being made for DRAFT-SCHWARTZ-SVCD-DNS by the ADD

I have read, and commented on, this document many times and I really like the current state of it. Please adopt.

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

---

From: Brian Dickson <[email-masked]>
Date: Mon, 27 Sep 2021 14:15:16 -0700

I oppose adoption of this draft by the ADD WG.

Here are the reasons:

   - This is a DNS binding, and belongs in the DNSOP WG
   - This is a sibling to the HTTPS-SVC draft, which is a DNSOP WG
   proposal/draft
   - The two ADD drafts listed may require SOME sort of DNS SVCB binding,
   but more input on what the requirements should be for the DNS SVCB binding
   - There are other drafts in DPRIVE and DNSOP that either require, or
   provide, a DNS SVCB binding
   - Those other DPRIVE/DNSOP drafts have requirements not met by the ADD
   draft
   - There are some incompatibilities between this draft and the
   corresponding DNSOP draft

I would propose first moving this draft to DNSOP, and then having reviews
done there by the participants, prior to any WG adoption call.

Brian Dickson

---

From: "Deen, Glenn" <[email-masked]>
Date: Mon, 27 Sep 2021 21:24:22 +0000

Hi Brian,

This reason this draft is being considered in ADD is that the chairs of both DNSOP and ADD discussed where it belonged and agreed that it would be handled in ADD after the main SVCB draft had been dealt with in DNSOP.      With the main SVCB having moved through DNSOP is was time to raise this draft for consideration in ADD.

You’re right it could also be handled in DNSOP, but given the significant participant overlap between the groups, and that this one is specifically related to ADD, it was decided by the combined chairs to do it in ADD.

Hope that helps with your concerns.

Regards
Glenn,  ADD co-chair

On 9/27/21, 2:15 PM, "Brian Dickson" <[email-masked]<mailto:[email-masked]>> wrote:

Here are the reasons:
·         This is a DNS binding, and belongs in the DNSOP WG
·         This is a sibling to the HTTPS-SVC draft, which is a DNSOP WG proposal/draft
·         The two ADD drafts listed may require SOME sort of DNS SVCB binding, but more input on what the requirements should be for the DNS SVCB binding
·         There are other drafts in DPRIVE and DNSOP that either require, or provide, a DNS SVCB binding
·         Those other DPRIVE/DNSOP drafts have requirements not met by the ADD draft
·         There are some incompatibilities between this draft and the corresponding DNSOP draft
I would propose first moving this draft to DNSOP, and then having reviews done there by the participants, prior to any WG adoption call.

Brian Dickson

On Tue, Sep 14, 2021 at 4:57 PM IETF Secretariat <[email-masked]<mailto:[email-masked]>> wrote:

The document is available at
https://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-schwartz-svcb-dns/__;!!CQl3mcHX2A!XoiUAPqhCr-cwYfqIgpxPt9i-7qJ_5xT2DBhSncZkyMLf_u28KWFUhIc-IiO8mgy8A$>

Comment:

Please send your comments on this WG Adoption call to the ADD list
([email-masked]<mailto:[email-masked]>).

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/add__;!!CQl3mcHX2A!XoiUAPqhCr-cwYfqIgpxPt9i-7qJ_5xT2DBhSncZkyMLf_u28KWFUhIc-IhlSEvhkQ$>

---

From: Brian Dickson <[email-masked]>
Date: Mon, 27 Sep 2021 15:59:29 -0700

I just read the companion drafts in ADD.

I think my concerns would be mitigated with the following changes:

   - Explicitly limit the use case to recursive server(s)
   - Change the binding to a different mnemonic/label that does not squat
   on the "dns" label which may be more applicable to an authoritative server.
   I'd suggest "resolver", as it is consistent with usage from the DNS
   terminology RFC (but I haven't looked at that lately, so I may be
   misremembering the terminology).

As long as this does not eventually conflict with an SVCB binding for a DNS
authoritative server (something I'm working on in DNSOP), I think it would
be okay to adopt in ADD.

Brian

On Mon, Sep 27, 2021 at 2:25 PM Deen, Glenn <[email-masked]> wrote:

> Hi Brian,
>
>
>
> This reason this draft is being considered in ADD is that the chairs of
> both DNSOP and ADD discussed where it belonged and agreed that it would be
> handled in ADD after the main SVCB draft had been dealt with in DNSOP.
>   With the main SVCB having moved through DNSOP is was time to raise this
> draft for consideration in ADD.
>
>
>
> You’re right it could also be handled in DNSOP, but given the significant
> participant overlap between the groups, and that this one is specifically
> related to ADD, it was decided by the combined chairs to do it in ADD.
>
>
>
> On 9/27/21, 2:15 PM, "Brian Dickson" <[email-masked]>
> wrote:
>
>
>
> ·         The two ADD drafts listed may require SOME sort of DNS SVCB
> binding, but more input on what the requirements should be for the DNS SVCB
> binding
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-schwartz-svcb-dns/__;!!CQl3mcHX2A!XoiUAPqhCr-cwYfqIgpxPt9i-7qJ_5xT2DBhSncZkyMLf_u28KWFUhIc-IiO8mgy8A$>
>
> Comment:
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/add__;!!CQl3mcHX2A!XoiUAPqhCr-cwYfqIgpxPt9i-7qJ_5xT2DBhSncZkyMLf_u28KWFUhIc-IhlSEvhkQ$>
>
>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 28 Sep 2021 10:14:59 -0400

On Mon, Sep 27, 2021 at 6:59 PM Brian Dickson <[email-masked]>
wrote:

> As long as this does not eventually conflict with an SVCB binding for a
> DNS authoritative server (something I'm working on in DNSOP), I think it
> would be okay to adopt in ADD.
>

Hi Brian,

The binding here is deliberately independent of recursive vs. authoritative
roles.  It is simply a binding for the DNS protocol.  Recursive vs.
authoritative is not strictly a property of a DNS server (or client);
rather, it is a property of an individual message (RD=0/1, AA=0/1).  In
some cases, a single server may offer both functions, or they may be mixed
in some fashion.  For example, there is a draft currently under
consideration in ADD [1] that uses a hybrid approach to identify resolvers
that are also authoritative for certain domains.

Also, many codebases combine stub, recursive, and authoritative
functionality.  Providing a unified mapping, independent of role,
simplifies implementation by improving separation between transport setup
and message contents.

I'm not aware of any conflict between this draft and any of the active
proposals in DNSOP or DPRIVE.  However, if we discover a need for further
SvcParams in some DNS use case, we can certainly define them, either in
this document or a subsequent one.

--Ben Schwartz

[1]
https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns-06

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Sep 2021 08:36:08 -0700

I agree with Ben's response to Brian. I also agree with the many other 
people who would like to see this document proceed in the ADD WG.

Limiting the use case inherently leads to additional documents for 
additional use cases. The DPRIVE WG has an additional, well-discussed 
use case. The group of WG chairs and ADs have discussed where the two 
use cases should be handled, and it was agreed that if the ADD and 
DPRIVE use cases could be dealt with in a single document in ADD, that 
was fine to do so.

--Paul Hoffman