Subject: [dns-privacy] A Few More Suggestions for the Requirements Draft

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 19 Apr 2021 15:08:40 +0000

I have a few more suggestions for draft-ietf-dprive-phase2-requirements. In Section 5.1:

After the current requirement #7, I'd like to suggest adding a requirement like this to make it clear that the authoritative name server determines if server authentication is required, or not:

"The authoritative domain owner or their administrator MUST have the option to specify whether server authentication is required for all secure connections to the server."

After the current requirement #9, I'd like to suggest a requirement like this to help make it clear that it's possible to the different name servers hosting a zone to have different secure connection requirements, and a recursor needs to be able to adapt appropriately:

The recursor MUST have the option to vary its connection behavior on an authoritative name server to name server basis. This SHALL include whether a secure transport protocol MUST always be used (non-downgradable) or whether a secure transport protocol MAY be used on an opportunistic (not strict) basis in recognition that some servers for a domain might use a secure transport protocol and others might not.

I'd like to propose a slight modification to number 10. An implementation may have an internal specification of preferences for its own purpose. For instance, a transport preferences cache. Access to that cache wouldn't require use of the DNS, so I think it makes sense to note that the requirement for DNS use is for access by others:

OLD
10. The specification of secure transport preferences MUST be performed using the DNS and MUST NOT depend on non-DNS protocols.

NEW:
10. The specification of secure transport preferences, when published for access by other parties, MUST be performed using the DNS and MUST NOT depend on non-DNS protocols.

I think we need to add a normative reference to RFC 8446 in the current #11:

OLD:
For secure transports using TLS, TLS 1.3 (or later versions) MUST be supported and downgrades from TLS 1.3 to prior versions MUST not occur.

NEW:
For secure transports using TLS, TLS 1.3 ([RFC8446] or later versions) MUST be supported and downgrades from TLS 1.3 to prior versions MUST not occur.

Do these seem reasonable? I'll close with a question: we've talked about server authentication, but not about client authentication. We should say something in the requirements draft about client authentication, but right now I'm not sure of what makes the most sense. OPTIONAL, REQUIRED, something else?

Scott

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Apr 2021 17:14:30 +0000

On Apr 19, 2021, at 8:08 AM, Hollenbeck, Scott <shollenbeck=[email-masked]> wrote:
> I have a few more suggestions for draft-ietf-dprive-phase2-requirements.

Before we start making point-level suggestions for the draft, it would be useful to know whether the draft is still being worked on, and what its expected status will be. The draft has not been updated in nearly six months, even though the authors said they would after the IETF meeting five months ago. My feeling from that is that the authors have lost interest, and maybe the WG has as well.

The purpose of the draft has shifted significantly. The -02 draft changed from "requirements" to "requirements and considerations". The meat of the draft (Section 5) is no longer requirements, but "features"; however, there are still MUST and SHOULDs among those features.

If the WG continues to work on this document, it would be good to first say what it's new purpose is (such as requirements on solutions documents), and whether it should be expected to be published as an RFC or just kept as a checklist before the WG moves other documents forward.

--Paul Hoffman

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 19 Apr 2021 17:25:31 +0000

> -----Original Message-----
> From: dns-privacy <[email-masked]> On Behalf Of Paul
> Hoffman
> Sent: Monday, April 19, 2021 1:15 PM
> To: [email-masked]
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] A Few More Suggestions for the
> Requirements Draft
>
> On Apr 19, 2021, at 8:08 AM, Hollenbeck, Scott
> <shollenbeck=[email-masked]> wrote:
> Before we start making point-level suggestions for the draft, it would be
> useful to know whether the draft is still being worked on, and what its
> expected status will be. The draft has not been updated in nearly six months,
> even though the authors said they would after the IETF meeting five months
> ago. My feeling from that is that the authors have lost interest, and maybe
> the WG has as well.
>
> The purpose of the draft has shifted significantly. The -02 draft changed from
> "requirements" to "requirements and considerations". The meat of the draft
> (Section 5) is no longer requirements, but "features"; however, there are still
> MUST and SHOULDs among those features.
>
> If the WG continues to work on this document, it would be good to first say
> what it's new purpose is (such as requirements on solutions documents), and
> whether it should be expected to be published as an RFC or just kept as a
> checklist before the WG moves other documents forward.

That would be a good discussion to have. The WG charter currently says this:

"Develop requirements for adding confidentiality to DNS exchanges between recursive resolvers and authoritative servers (unpublished document)."

Does that need to change?

Scott

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Apr 2021 17:52:31 +0000

On Apr 19, 2021, at 10:25 AM, Hollenbeck, Scott <shollenbeck=[email-masked]> wrote:
> The WG charter currently says this:
> 

I don't think so, because the WG has been actively developing those requirements without the draft moving forward, just by having good WG discussions. Maybe the current document can just expire gracefully?

--Paul Hoffman

---

From: Danny McPherson <[email-masked]>
Date: Mon, 19 Apr 2021 13:58:47 -0400

On 2021-04-19 13:52, Paul Hoffman wrote:
> 
> I don't think so, because the WG has been actively developing those
> requirements without the draft moving forward, just by having good WG
> discussions.

Not sure what that means.  Is there a summary of those "good WG 
discussions" and where consensus may or may not exist?

I'd prefer to have some succinct and comprehensive requirements here 
before finishing all the solutioning...

-danny

---

From: Brian Haberman <[email-masked]>
Date: Mon, 19 Apr 2021 16:43:47 -0400

> before finishing all the solutioning...

The goal of the referenced work item is to ensure that the WG
participants agree on the requirements. Having that be done in a draft
is far cleaner than relying on various people's recollections of
discussions.

If everyone goes back to the minutes of our session during IETF 110,
Benno explicitly told the WG that he is happy to work on a revision
*with WG input*. I view Scott's messages to the ML as being an attempt
to provide such feedback to the draft authors on what he sees as useful
changes to the draft. Scott's suggestions should be discussed to see
what suggestions have consensus.

Regards,
Brian

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Apr 2021 20:51:14 +0000

On Apr 19, 2021, at 1:43 PM, Brian Haberman <[email-masked]> wrote:
> participants agree on the requirements.

Great, but then we're back to the question of what are "requirements", particularly because the current draft has moved away from that.

> Having that be done in a draft

Fully agree, if we can agree what the base is.

> what suggestions have consensus.

That feels premature, given that we don't actually know what the document is supposed to be about.

--Paul Hoffman

---

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

Hi Paul,

> Great, but then we're back to the question of what are "requirements", particularly because the current draft has moved away from that.

I agree that the current draft is not just about requirements. If I
recall, that came about because some WG participants pushed back on hard
requirements and really just wanted "design considerations".

My view, as a WG participant, is that we need to decide how we want to
use this document.

> That feels premature, given that we don't actually know what the document is supposed to be about.

Then let's start with a conversation about what the WG wants out of this
document. I'll start a separate thread for that.

Regards,
Brian