Subject: Re: [dns-privacy] Second Working Group Last Call for draft-ietf-dprive-bcp-op

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 1 Nov 2019 11:38:31 +0100

On Thu, Oct 31, 2019 at 11:24:45AM -0400,
 Tim Wicinski <[email-masked]> wrote 
 a message of 113 lines which said:

> This starts a Second Working Group Last Call for draft-ietf-dprive-bcp-op

Background: I run a small (very small) public DoH and DoT resolver,
and it has a DROP (a policy). If you want to read it, it is only in
french: <https://doh.bortzmeyer.fr/policy>. I checked it against
section 6 and appendix C.

Executive summary: the draft is fine and useful and, IMHO, should be
published.

A few issues:

* the first paragraph of section 4 should be deleted since the draft
does not use RFC2119 (and rightly so), except one lonely SHOULD in
section 5.

* "A DNS privacy service must be engineered for high availability."
I'm not in favor of this sentence. 1) It seems to despise small
resolvers managed by small organisations, while we need many diverse
DoT and DoH resolvers, to avoid centralisation 2) Today, Firefox,
unfortunately, does not allow to add more than one DoH resolver, which
makes the DoH resolver a very critical resource. But I hope that in
the future, we will be able to configure several resolvers, with an
efficient fallback, making the issue of availability less important.

* DROP is not a perfect acronym since the draft does not talk only
about privacy but also about integrity ("result filtering", aka lying
resolvers).

* "exporting DNS traffic from the resolver using e.g. dnstap" May be a
reference to section 6.1.1 about sharing could be a good idea? Today,
many existing policies say things like "we don't store logs for more
than N weeks" but are silent on export/sharing...

* "Aggressive Use of DNSSEC-Validated Cache [RFC8198] to reduce the
number of queries to authoritative servers to increase privacy" RFC
8020 could be mentioned, too, for the same goal.

* Appendix B is really good and useful. "The level of anonymization
this [keeping a /24 for IPv4] produces is perhaps questionable" is
certainly the understatement of the year :-)

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 1 Nov 2019 12:28:05 +0100

> about privacy but also about integrity ("result filtering", aka lying

It's even possible to keep the acronym and just tweak the name, e.g. DNS
Recursive Operator Policy.  In any case, does it matter? I didn't think
the acronym was expected/intended to spread much beyond the RFC itself.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 1 Nov 2019 12:34:07 +0100

On Fri, Nov 01, 2019 at 12:28:05PM +0100,
 Vladimír Čunát <[email-masked]> wrote 
 a message of 8 lines which said:

> In any case, does it matter?

No. As I said, I think the draft is ready, the issues I raised were
mostly details.

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 6 Nov 2019 13:16:29 +0000

> From: Stephane Bortzmeyer <[email-masked]>
> Subject: Re: [dns-privacy] Second Working Group Last Call for draft-ietf-dprive-bcp-op
> Date: 1 November 2019 at 10:38:31 GMT
> To: Tim Wicinski <[email-masked]>
> Cc: [email-masked]
> 

Hi Stephane,

Thanks for the review!

> does not use RFC2119 (and rightly so), except one lonely SHOULD in

The current usage is the result of a discussion on the very first version of the draft (draft-dickinson-dprive-bcp-op-00, June 2018) and since then (limited) usage of RFC2119 language has been present. There have been comments on both sides that the language should be stronger and weaker and this was the compromise outcome. The SHOULD does ripple through the document though as it defines all the Mitigations listed in the later sections as being recommended for minimal compliance. How much of an issue is this for you?

> efficient fallback, making the issue of availability less important.

I can understand this reading of it but item 1 you list above was not at all the goal of this at all text. Perhaps this could be better phrased as 
“A DNS privacy service should strive to engineer encrypted services to the same availability level as any unencrypted services they provide.”?

> about privacy but also about integrity ("result filtering", aka lying

It seems is the best one offered yet - as mentioned previously bike-shedding on this is always an option… Vladimir suggested DNS Recursive Operator Policy but that seems a little too general to me given the limited scope of the document (Privacy services). Do you have a suggestion?

Also, one distinction is that the privacy related policy outlined in a DROP can be directly assessed against the privacy mitigations outlined in this document to determine a compliance level, whereas the document makes no statements about filtering policy requirements. The aim of including them in the DROP is purely for transparency.

> than N weeks" but are silent on export/sharing…

Or perhaps a reference to Section 5.2 is better as it lists the threats and mitigations in detail?

> 8020 could be mentioned, too, for the same goal.

Sure.

> certainly the understatement of the year :-)

:-)

Best regards

Sara.

---

From: Christoph <[email-masked]>
Date: Thu, 07 Nov 2019 00:17:00 +0000

Stephane Bortzmeyer wrote:> * "A DNS privacy service must be engineered
for high availability."
> unfortunately, does not allow to add more than one DoH resolver,
> which makes the DoH resolver a very critical resource. But I hope
> that in the future, we will be able to configure several resolvers,
> with an efficient fallback, making the issue of availability less
> important.

I second that.

> “A DNS privacy service should strive to engineer encrypted services
> to the same availability level as any unencrypted services they
> provide.”?

Sounds good to me.

> * DROP is not a perfect acronym 
+1
maybe "DROPS"?

> "be held only memory"

"in memory.."

kind regards,
Christoph

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 7 Nov 2019 16:57:03 +0100

On Wed, Nov 06, 2019 at 01:16:29PM +0000,
 Sara Dickinson <[email-masked]> wrote 
 a message of 241 lines which said:

> The current usage is the result of a discussion on the very first
> version of the draft (draft-dickinson-dprive-bcp-op-00, June 2018)
> and since then (limited) usage of RFC2119 language has been
> present. There have been comments on both sides that the language
> should be stronger and weaker and this was the compromise
> outcome. The SHOULD does ripple through the document though as it
> defines all the Mitigations listed in the later sections as being
> recommended for minimal compliance. How much of an issue is this for
> you?

Not too important. 

> I can understand this reading of it but item 1 you list above was
> not at all the goal of this at all text. Perhaps this could be
> better phrased as “A DNS privacy service should strive to engineer
> encrypted services to the same availability level as any unencrypted
> services they provide.”?

OK, fine.

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 11 Nov 2019 11:37:34 +0000

> On 7 Nov 2019, at 15:57, Stephane Bortzmeyer <[email-masked]> wrote:
> 

Thanks - will update!

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 11 Nov 2019 11:37:30 +0000

> On 7 Nov 2019, at 00:17, Christoph <[email-masked]> wrote:
> 

Thanks.

> maybe "DROPS”?

Right now it is ‘DNS Recursive Operator Privacy’ statement. I think if we added ’Security’ (as I think you are suggesting) then I suspect a comment would be that it should include a lot more than it currently does if it is to cover all aspects of ’security’ because that is a broad term…...

> "in memory.."

Fixed!

Sara.