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

[Sara Dickinson <[e-mail]>]

> From: Stephane Bortzmeyer <[e-mail]>
> 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 <[e-mail]>
> Cc: [e-mail]
> 
> On Thu, Oct 31, 2019 at 11:24:45AM -0400,
> Tim Wicinski <[e-mail]> 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.

Hi Stephane,

Thanks for the review!

> 
> 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.

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?

> 
> * "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.

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.”?

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

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.

> 
> * "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…

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

> 
> * "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.

Sure.

> 
> * 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 :-)

:-)

Best regards

Sara.