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

From: Tim Wicinski <[email-masked]>
Date: Fri, 16 Aug 2019 07:49:49 -0400

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

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/

The Current Intended Status of this document is: Best Current Practices

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please speak
out with your reasons.

This starts a two week Working Group Last Call process, and ends on: 30
August 2019

thanks
tim

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 16 Aug 2019 15:42:18 +0100

Hiya,

I had an hour so gave this a read. I like the draft
but think it's not ready quite yet. Depending on the
answer to my question at #1 below, that could all be
fixed before or just after the end of the WGLC though
but it might take a bit longer as there's more than a
teeny bit of work needed I'd say.

Substantive comments and nits below.

Cheers,
S.

#1: I wonder would we be better to wait until some real
operators have published DPPPS documents before making
this an RFC? I'd expect that there'll be some changes
when/if that happens (I'm assuming it's not yet happened
but didn't check.) If some such operator has said they'd
do that, but want to wait 'till there's an RFC, then
that's a good enough reason to go ahead now. If we just
don't know, then going ahead and recording this in an
RFC is probably ok, but risks this not being followed
much or at all.

#2: I think a sample DPPPS document should at least
exist and be referenced from this or included as an
appendix. Is there one somewhere? If not, then I think
we really ought fix that before publication.

#3: Perhaps we should ask the pearg and httpbis folks if
there's any more/better guidance to add to 5.1.3.2?
IIRC a pearg presentation at IETF105 seems to have
indicated that some h2 session management stuff might
also assist with traffic analysis. Checking that out
before publication would seem worthwhile in case there's
more to usefully say here.

#4: 5.1.4: the lowercase "must" for DNSSEC validation is
odd. I'd like a "MUST" but perhaps that's not feasible
now?

#5: given that 1% of zones are signed, and that DNSSEC
answers are big, do we think padding is sufficient to
prevent an observer from knowing when a qname is in the
1%? If so, great! (But really?;-) If not, is that a
problem worth mentioning? And is there anything one could
do about it?

#6: I don't think mention of "consent" is a good thing
to positively recommend operators do as there is (afaik)
no good way to really do that. The idea that whatever is
behind a DNS stub client can meaningfully "consent" to
something is really just broken IMO.  (Mentioning that
one cannot assume consent is fine, but saying to go get
it, when that makes no sense, isn't fine IMO.) Same
applies to 6.1.1 item 7.

#7: 6.1.1, item 3: "sold or rented" - heh - good luck
with that;-) Why not just say doing that's a "MUST NOT"?
What operator adhering to this BCP would really be
selling or renting the data? I would hope none, and that
the BCP calls that out as non-conforming.

#8: 6.1.1, item 6: That all looks too heavy to actually
be done by any of the bigger folks who use anycast - are
we really expecting them to list all the local laws that
might apply?  What use would that be to someone
selecting an operator really? While some information
about jurisdictions ought be part of this, I think that
needs more thought.

nits:

- abstract: Is "DNS operators" right? Maybe this is
  really just "DNS recursive resolver operators" and
doesn't include advice for authoritative server
operators? Probably better to have the abstract
correct.

- DPPPS: that's not a great term, hard to say and hard
to remember how many P's - I'd suggest a bit of creative
bacronyming might be worthwhile - I'll start the bikeshed
painting with "DNS Recursive Operator Privacy statement"
or "DROP statement":-)

- I don't understand the bullet list just before section
  5.1, nor the preceding paragraph - what's it trying
to say?

- 5.1.2: X.509 probably needs a reference to rfc5280,
  but where do I go to find a definition of an "SPKI
pinset"? Later you point to rfc7858 for that but I don't
find the term "pinset" used in there - "pin set" (with a
space) is used in appendix A there, so maybe that's the
reference you want.

- 5.1.2: (sadly) maybe it'd be better to remove the
  mention of the DNSSEC chain extension draft. I suspect
it'd just confuse readers of an RFC later.

- 5.1.2: Is anyone publishing TLSA for DoT/DoH servers?
  If so, great! If not, "can also consider" mightn't be
worth saying.

- 5.1.3.1: the link at [1] seems broken? I didn't check
  all others, but someone should:-)

- 5.1.3.1: Maybe say using RFC8467 or a successor
  specification? It's pretty early days to be very
confident in that RFC. (Much though I like it.)

- 5.1.7: Is "Operator" in the section heading here
  really the operator of the DNS privacy service?
Better to be clear about that. People might think you
mean n/w operators between the stub and recursive.

- 5.2.3: The content of [10] really needs to be in the
  document body, or else the text above it needs to
change.

- 5.3.1: The "NOTE" that the authors may add something
  later needs fixing.

- 5.3.2: The "pitfalls" link reference is broken I
  think.

- 6.1.1, item 2: add "and for how long and how those
  logs are handled" (and maybe more) - this bullet also
overlaps with item 3, so maybe it'd be better to
re-organise this list a bit?

- section 8: A "TODO" there isn't gonna work really:-)

---

From: Sara Dickinson <[email-masked]>
Date: Fri, 23 Aug 2019 17:54:25 +0100

> On 16 Aug 2019, at 15:42, Stephen Farrell <[email-masked]> wrote:
> 
> Hiya,
> 

Hi Stephen,

Thanks so much for the detailed review!

> RFC is probably ok, but risks this not being followed

I admit we have a chicken and egg problem. Cloudflare, Google, Quad9 and several other operators have all published ‘privacy statements’ but in very differing formats (see
https://dnsprivacy.org/wiki/display/DP/Comparison+of+policy+and+privacy+statements,
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Public+Resolvers and
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers).

I don’t really see any motivation for them to update these until there is an RFC to follow and also I fully expect to bis this document in the foreseeable future as the landscape evolves. The consensus at IETF105 seemed to be to get on and publish this in preference to waiting some unknown time for operator movement.

> we really ought fix that before publication.

I like that idea. I think an example in the Appendix could work well and could even be based on one of the existing policies :-)

> more to usefully say here.

I’ve mentioned this off-list to a couple fo PEARG folks, but I think sending mail to those groups makes sense too.

> odd. I'd like a "MUST" but perhaps that's not feasible

There was a discussion early in the life of the document about how prescriptive it could/should be because it was a BCP and the approach taken after that was not to use normative language throughout the document and instead just to use the 3 categories defined at the end of section 5 with a SHOULD there:

“This document does not specify policy only best practice, however for
   DNS Privacy services to be considered compliant with these best
   practice guidelines they SHOULD implement (where appropriate) all:

   o  Threat mitigations to be minimally compliant

   o  Optimizations to be moderately compliant

   o  Additional options to be maximally compliant"

DNSSEC is classed as a Threat Mitigation so it falls into the top category. If folks want to revisit this general approach then now is the time :-)

> problem worth mentioning? And is there anything one could

It is a good question, but I’m not sure this document should do anything other than recommend following the guidelines in RFC8467? Also, I think that only applies if the client is directly requesting the DNSSEC records from the resolver so it can do validation itself (which virtually none do today…..), otherwise the resolver just sends the same answer with the AD set appropriately for both signed and unsigned responses.

FYI: My understanding is that an update to RFC8467 is highly likely given the recent research on website fingerprinting presented in PEARG at IETF 105:
https://datatracker.ietf.org/meeting/105/materials/slides-105-pearg-encrypted-dns-privacy-a-traffic-analysis-perspective

> it, when that makes no sense, isn't fine IMO.) Same

For the subset of operators with ‘contracts' with users e.g. ISPs it seems entirely possible to obtain consent? For others, I agree - it is untested.

> the BCP calls that out as non-conforming.

So Section 5.3.3 is actually the part that describes what operators need to do for compliance and that does say “should not provide identifiable data to third-parties  without explicit consent from clients"

Section 6.1.1 is just stating what a DPPPS should contain, regardless of the level of compliance of the operator. I see a DPPPS as serving to let client know how an operator might deviate from complying from the BCP so shouldn’t necessarily be limited to only those that do comply?

> about jurisdictions ought be part of this, I think that

Item 6.1.2?

I didn’t read the section that way so it probably needs some clarification. I understood points 1 and 2 to apply to just the legal entity of the operator (e.g. Google would specify US) and point 3 is just a list of the counties the anycast servers are located in. Would be interested to hear other views on this.

> operators? Probably better to have the abstract

Section 2 makes the scope clear ‘'However this
   document is limited in scope to best practice considerations for the
   provision of DNS privacy services by servers (recursive resolvers) to
   clients (stub resolvers or forwarders).”

but it wouldn’t hurt to tidy up the abstract :-)

> painting with "DNS Recursive Operator Privacy statement"

It is a total mouthful but the idea was to roughly follow but not collide with RFC6841 which describes a DP (DNSSEC Policies) and a DPS (DNSSEC Practice Statement). I’m liking DROP, but let the bikeshedding begin :-)

>  5.1, nor the preceding paragraph - what's it trying

It goes back again to the discussion about how prescriptive the document should be. The very first drafts had those 3 categories of actions as MUST/SHOULD/MAY options for operators in each section but there was push back against it so the current text is an attempt to convey more of a ’traffic light’ system of compliance.

> space) is used in appendix A there, so maybe that's the

Yup - it should be ‘pin set’ and this should also reference RFC8310 for authentication methods based on pin sets.

> it'd just confuse readers of an RFC later.

Ack. I lived in hope of its resurrection but since it hasn’t happened I’ll yank that text.

>  If so, great! If not, "can also consider" mightn't be

Only a few of the individual test servers at the moment, none of the big players to my knowledge. That is why is is only an optimisation...

>  all others, but someone should:-)

Will fix.

> confident in that RFC. (Much though I like it.)

Will do.

> mean n/w operators between the stub and recursive.

Right, this section is designed to inform the DNS privacy service operator (I’ll update the heading)

>  document body, or else the text above it needs to

Ack - will see what SVG magic can be done or will convert to ASCII art...

> - 5.3.1: The "NOTE" that the authors may add something

Indeed - I’ll follow up with Roland as I believe he was aware of work on this.

> - 5.3.2: The "pitfalls" link reference is broken I

Yup - will fix…..

> re-organise this list a bit?

Fair point. I think merging 2 into 3 would be best?

> - section 8: A "TODO" there isn't gonna work really:-)

I thought I had zapped them all but missed that one…. thanks. I’m not sure we have much more to say beyond what is in RFC7766 so I think the intention had been to just remove that unless anyone wants to suggest text?

FYI - I am out of the office next week so will follow up on any further discussion as soon as I am back!

Best regards

Sara.