Subject: [dns-privacy] How do we want to use draft-ietf-dprive-phase2-requirements?

From: Brian Haberman <[email-masked]>
Date: Mon, 19 Apr 2021 17:13:02 -0400

All,
     As was raised on the thread discussing suggestions for the
requirements draft, there is some question on how the WG wants to use
draft-ietf-dprive-phase2-requirements in progressing our
recursive-to-authoritative privacy work item. The draft currently has
one sub-section that describes requirements (5.1) and another section
that describes optional features (5.2), albeit with 2119 SHOULDs.

     My question to the WG is how do we want to use this draft? I see
four possible approaches, but I am sure someone will point out others.

1. Strictly requirements - these would be MUST-level functions that the
WG determines have to be supported by any solutions draft.

2. Strictly design considerations - these would be functional areas that
the WG determines need to be considered, but not necessarily included,
by any solutions draft.

3. Requirements & design considerations - This is generally where the
current draft sits IMO.

4. Drop the draft and let the solutions flow.

Let's discuss the focus of the draft and then we can determine what
updates are needed/necessary.

Regards,
Brian

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 20 Apr 2021 12:19:56 +0000

> -----Original Message-----
> From: dns-privacy <[email-masked]> On Behalf Of Brian
> Haberman
> Sent: Monday, April 19, 2021 5:13 PM
> To: [email-masked]
> Subject: [EXTERNAL] [dns-privacy] How do we want to use draft-ietf-dprive-
> phase2-requirements?
> 
> All,
>      As was raised on the thread discussing suggestions for the requirements
> draft, there is some question on how the WG wants to use draft-ietf-dprive-
> phase2-requirements in progressing our recursive-to-authoritative privacy
> work item. The draft currently has one sub-section that describes
> requirements (5.1) and another section that describes optional features
> (5.2), albeit with 2119 SHOULDs.
> 
>      My question to the WG is how do we want to use this draft? I see four
> possible approaches, but I am sure someone will point out others.
> 
> 1. Strictly requirements - these would be MUST-level functions that the WG
> determines have to be supported by any solutions draft.
> 
> 2. Strictly design considerations - these would be functional areas that the
> WG determines need to be considered, but not necessarily included, by any
> solutions draft.
> 
> 3. Requirements & design considerations - This is generally where the current
> draft sits IMO.
> 
> Let's discuss the focus of the draft and then we can determine what updates
> are needed/necessary.

I prefer option #3, but with a change in order such that we describe design considerations first, followed by requirements that are derived from those considerations.

Scott

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Apr 2021 16:59:32 +0000

> 4. Drop the draft and let the solutions flow.

As a document author, I prefer #4 but with a modification: every solution document must have an honest, readable Security Considerations section that covers the design considerations. By "honest", I mean that the text there needs to have WG consensus, including of the people who have a different preferred solution. 

My rationale for no longer needing a separate document is that the WG discussion of adopting the opportunistic/unauthenticated draft, and the possible adoption of the fully-authenticated draft, has pretty much fully brought out all the requirements and design considerations for both proposals. 

--Paul Hoffman

---

From: Peter van Dijk <[email-masked]>
Date: Thu, 22 Apr 2021 17:27:38 +0200

> My rationale for no longer needing a separate document is that the WG discussion of adopting the opportunistic/unauthenticated draft, and the possible adoption of the fully-authenticated draft, has…

This makes sense to me. The explored solution space (which is way
bigger than the viable solution space!) has covered so much ground,
we've basically already seen it all. So, it is better to judge each
proposal on its own, honestly stated indeed, merits (and demerits).

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

---

From: Brian Haberman <[email-masked]>
Date: Mon, 26 Apr 2021 15:44:36 -0400

Does anyone else have an opinion on this?

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 Apr 2021 18:11:48 -0700

I also prefer #4.

On Mon, Apr 26, 2021 at 12:45 PM Brian Haberman <[email-masked]>
wrote:

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Andrew Campling <[email-masked]>
Date: Tue, 27 Apr 2021 21:24:56 +0000

>> 1. Strictly requirements - these would be MUST-level functions that 
>> the WG determines have to be supported by any solutions draft.
>> 
>> 2. Strictly design considerations - these would be functional areas 
>> that the WG determines need to be considered, but not necessarily 
>> included, by any solutions draft.
>> 

Building on the Root Server Operators Statement on DNS Encryption, I think there would be benefit in gaining input from TLD operators to establish whether they are interested in adopting encryption, as well as any insight into deployment considerations, the relative attractiveness of potential solutions etc.  Developing solutions without sufficient understanding of the requirements and operational concerns of the intended beneficiaries risks wasting a lot of effort pursuing the wrong solutions to the wrong problems.  Capturing this information would seem to fit within a requirements document.  

Andrew