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

[Sara Dickinson <[e-mail]>]

> Begin forwarded message:
> 
> From: Stephen Farrell <[e-mail]>
> Subject: Re: [dns-privacy] Working Group Last Call for draft-ietf-dprive-bcp-op
> Date: 19 September 2019 at 13:33:28 BST
> To: Sara Dickinson <[e-mail]>
> Cc: [e-mail]
> 
> 
> Hi Sara,
> 
> Sorry for being slow responding…

Sorry myself for a slow update…..

> 
> I think the only bits below where I'm still concerned
> are the ones relating to (so-called:-) "consent." I'd
> be happy to continue discussing that but even happier
> if we didn't depend on the (IMO dodgy) concept. Other
> than that, I guess another rev should resolve all the
> issues I raised.
> 
> On 23/08/2019 17:54, Sara Dickinson wrote:
>> 
>> 
>>> On 16 Aug 2019, at 15:42, Stephen Farrell
>>> <[e-mail]> wrote:
>>> 
>>> #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.
>> 
>> 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 :-)
> 
> That'd be great.

Thanks again for this idea - it was a really good exercise as it made me go back and tweak the original structure of the statement and add a section about upstream capabilities which was missing. Please review.

I’ve taken a first pass at this for a specific example as an Appendix… I think it needs some work and a different or another example might be needed but I do think this helps clarify the whole idea.

>>> 
>>> #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.
>> 
>> 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.
> 
> I guess I maintain my position though - a BCP that says
> to "somehow" arrange for some ill-defined (and oft abused)
> "consent" isn't a good plan.

Ah, I see. I don’t believe at this stage the idea was to specify or define what consent _should_ mean (since it is probably impossible and out of scope for this document!). Rather the reason for including this in the DROP was for operators to state for the record what *they* define as consent so that users are aware. Several policies today say ‘we won’t do X without consent’, but give no details about what that consent process might involve - this item is for operators to elaborate on that so that it is at least documented.

I’ve re-written the text in this point to try to better describe the requirement - see what you think.

> 
>>> #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.
>> 
>> 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"
> 
> "Consent" again? How many times is that honoured vs. abused
> by (web) service providers? I think far more the latter
> than the former. I'm against extending such pretense to the
> DNS.
> 
>> 
>> 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?
> 
> I don't understand that sorry. T

For example, you might have an operator that sells only anonymised data and their policy says they do this without requiring consent (as would be legal in the US AFAIK). They can state that here and then it is on the record (FWIIW) that they don’t sell their full data set, even thought it would be preferable that they don’t sell anything. I think that is better than having an implicit requirement that any operator that publishes a DROP statement doesn’t sell or rent anything at all.

Also, the introduction touches on the fact that it would be nice that _all_ DNS operators could use this format for consistency, so limiting it with implicit requirements seems restrictive?

> 
>> 
>>> 
>>> #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.
>> 
>> 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.
> 
> Same here. I've no idea if anycast DNS operators consider
> the unicast instances only need to adhere to the law where
> the operator entity is established or not. IANAL, but
> that'd seem odd. If unicast instances need to follow the
> local law where the instance is running, then this section
> could end up as 100 useless pages.

I’ve added a couple of words to try to make this clearer and I think the example will help….

> 
>> 
>>> 
>>> nits:
> 
> Your responses on the nits are all fine. I'll be happy to
> check the diffs when you e.g. fix the URLs etc.
> 
> The naming bikeshed discussion didn't happen I guess, so
> take that suggestion or leave it as you see best.

I’m going with DROP unless I hear otherwise….


> 
> Cheers,
> S.
> 
> 
>>> 
>>> - 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.
>> 
>> 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 :-)

Done.

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

As above.

>> 
>>> 
>>> - I don't understand the bullet list just before section 5.1, nor
>>> the preceding paragraph - what's it trying to say?
>> 
>> 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.
>> 
>>> 
>>> - 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.
>> 
>> Yup - it should be ‘pin set’ and this should also reference RFC8310
>> for authentication methods based on pin sets.

Done.

>> 
>>> 
>>> - 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.
>> 
>> Ack. I lived in hope of its resurrection but since it hasn’t happened
>> I’ll yank that text.

Done.

>> 
>>> 
>>> - 5.1.2: Is anyone publishing TLSA for DoT/DoH servers? If so,
>>> great! If not, "can also consider" mightn't be worth saying.
>> 
>> 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...
>> 
>>> 
>>> - 5.1.3.1: the link at [1] seems broken? I didn't check all others,
>>> but someone should:-)
>> 
>> Will fix.

Done, other links checked too.

>> 
>>> 
>>> - 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.)
>> 
>> Will do.

Done.

>> 
>>> 
>>> - 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.
>> 
>> Right, this section is designed to inform the DNS privacy service
>> operator (I’ll update the heading)

Done.

>> 
>>> 
>>> - 5.2.3: The content of [10] really needs to be in the document
>>> body, or else the text above it needs to change.
>> 
>> Ack - will see what SVG magic can be done or will convert to ASCII
>> art…

I’ve converted this to a table….


>> 
>>> 
>>> - 5.3.1: The "NOTE" that the authors may add something later needs
>>> fixing.
>> 
>> Indeed - I’ll follow up with Roland as I believe he was aware of work
>> on this.

Have removed.

>> 
>>> 
>>> - 5.3.2: The "pitfalls" link reference is broken I think.
>> 
>> Yup - will fix…..
>> 
>>> 
>>> - 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?
>> 
>> Fair point. I think merging 2 into 3 would be best?

Done.

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

Removed.

Best regards

Sara.