Subject: Re: [Doh] [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients

From: william manning <[email-masked]>
Date: Fri, 5 Apr 2019 09:43:12 -0700

Every now and then, Paul Vixie and I are in complete harmony.  In my
current slot, we are one of thousands of entities that are being held
accountable to a series of regulatory requirements that have significant
fiscal impacts on the exfiltration of private/patient data.  We are
starting to focus on three distinct areas to reduce the impact that DOH
presents to our security posture.  1) In contractual/proccurement
language.  We have some "Must have" items and now we will have "Must not"
items.  2) There are at least two technical options for tracking/blocking
DOH which are being turned into turnkey options to "swat" this covert C&C
channel.  3) Aggressive Browser Hygiene.

This genie has not signed BAA or supplier agreement with us and we will not
allow it to dictate our business processes or affect our liability without
the DOH enabler shouldering fiscal and legal exposure when DOH is shown to
be the culprit in exposure of private data.  I can't see how DOH is going
to pass GDRP muster inside the EU either, but that is for others to
debate.  I have told my GDRP affected counterparts about the privacy risks
with DOH deployment.

as usual, YMMV.

/William Manning

On Sun, Mar 10, 2019 at 8:26 PM nalini elkins <[email-masked]>
wrote:

>  > Similarly, putting DNS in user space allows for immediate adoption of
> DNSSEC and privacy enhancements, even when the operating system or the
> local network does not support them
>
> At enterprises (banks, insurance, etc) on their internal networks, people
> run their own DNS servers which may resolve for both internal and external
> sites.
>
> We were recently talking to a Fortune 50 company in the United States
> about what might happen you install a version of the browser which uses
> DNS-over-HTTPS automatically.  (Clearly, this applies to any variant.)
>
> The questions that the Fortune 50 company architect asked were something
> like this:
>
> 1. You mean that DNS could be resolved outside my enterprise?
>
> 2. So whoever that is that resolves my DNS sees the pattern and frequency
> of what sites my company goes to?
>
> 3. How do I change this?
>
> I look forward to a discussion on this issue..    There will be at least
> one enterprise present in Prague to speak for themselves.  I will see if I
> can get others to participate remotely.
>
> It would be good to also discuss how to warn enterprises that this is
> about to happen.   I wonder if an announcement via CERT or another group
> may be appropriate.
>
> Thanks,
> Nalini
>
> On Mon, Mar 11, 2019 at 6:36 AM Christian Huitema <[email-masked]>
> wrote:
>
>>
>> On 3/10/2019 4:07 PM, Vittorio Bertola wrote:
>> > Honestly, I understood it differently - at this point in time they are
>> > doing tests on whether their resolver performs better or worse than
>> > the system's one, but their announced model is that Firefox will adopt
>> > a DoH resolver (though it's unclear how it will be chosen) and it will
>> > just use that one. But if people from Mozilla could make a clearer
>> > announcement on what their plans currently are, that would be good.
>> > Still, most of the issues arise whenever an application, for whatever
>> > reason and under any mechanism, starts to use one or more resolvers
>> > different than the one set up in the operating system: even if it used
>> > more than one, you would still get many of the issues listed in the
>> > document (though, if it used more than one at the same time, I think
>> > you'd actually also get some new specific issues, so we'd need to add
>> > a discussion of this possibility).
>>
>>
>> Your view of operating systems and applications is firmly rooted in
>> history, which is another way to say in the past. The evolution in the
>> past years points to a systematic deconstruction of that relation, with
>> for example virtual machine, containers, or the trend to move network
>> stacks out of the operating system and into the application. This is
>> pretty obvious for security stacks, but it is also becoming very clear
>> with QUIC and transport stacks. There are two big drivers: portability,
>> and rapid adoption of innovation. These two drivers apply to DNS just
>> like they apply to transport.
>>
>> Putting QUIC in application space allows for immediate provision of
>> innovations like 0-RTT, head-of-queue blocking mitigation, or the better
>> crypto of TLS 1.3. Similarly, putting DNS in user space allows for
>> immediate adoption of DNSSEC and privacy enhancements, even when the
>> operating system or the local network does not support them. That genie
>> is not going back in the bottle any time soon.
>>
>> -- Christian Huitema
>>
>>
>> _______________________________________________
>> dns-privacy mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
>
>
> --
> Thanks,
> Nalini Elkins
> President
> Enterprise Data Center Operators
> www.e-dco.com
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Watson Ladd <[email-masked]>
Date: Sat, 6 Apr 2019 11:04:01 -0700

On Fri, Apr 5, 2019 at 9:45 AM william manning
<[email-masked]> wrote:
>
> Every now and then, Paul Vixie and I are in complete harmony.  In my current slot, we are one of thousands of entities that are being held accountable to a series of regulatory requirements that have significant fiscal impacts on the exfiltration of private/patient data.  We are starting to focus on three distinct areas to reduce the impact that DOH presents to our security posture.  1) In contractual/proccurement language.  We have some "Must have" items and now we will have "Must not" items.  2) There are at least two technical options for tracking/blocking DOH which are being turned into turnkey options to "swat" this covert C&C channel.  3) Aggressive Browser Hygiene.
>
> This genie has not signed BAA or supplier agreement with us and we will not allow it to dictate our business processes or affect our liability without the DOH enabler shouldering fiscal and legal exposure when DOH is shown to be the culprit in exposure of private data.  I can't see how DOH is going to pass GDRP muster inside the EU either, but that is for others to debate.  I have told my GDRP affected counterparts about the privacy risks with DOH deployment.

You know you can just turn it off the same way you configure your
devices on your network. I also don't understand the GDRP issue you
raise: surely all DNS services have the same problems.

I'm more than happy to show you how to click the checkbox to turn it
off in Firefox. In fact there is a checkbox you need to click to turn
it on, and you can customize it at will. (I literally just checked)

> as usual, YMMV.
>
> /William Manning
>
> On Sun, Mar 10, 2019 at 8:26 PM nalini elkins <[email-masked]> wrote:
>>
>>  > Similarly, putting DNS in user space allows for immediate adoption of DNSSEC and privacy enhancements, even when the operating system or the local network does not support them
>>
>> At enterprises (banks, insurance, etc) on their internal networks, people run their own DNS servers which may resolve for both internal and external sites.
>>
>> We were recently talking to a Fortune 50 company in the United States about what might happen you install a version of the browser which uses DNS-over-HTTPS automatically.  (Clearly, this applies to any variant.)
>>
>> The questions that the Fortune 50 company architect asked were something like this:
>>
>> 2. So whoever that is that resolves my DNS sees the pattern and frequency of what sites my company goes to?
>>
>> 3. How do I change this?
>>
>> I look forward to a discussion on this issue..    There will be at least one enterprise present in Prague to speak for themselves.  I will see if I can get others to participate remotely.
>>
>> It would be good to also discuss how to warn enterprises that this is about to happen.   I wonder if an announcement via CERT or another group may be appropriate.
>>
>> Thanks,
>> Nalini
>>
>> On Mon, Mar 11, 2019 at 6:36 AM Christian Huitema <[email-masked]> wrote:
>>>
>>>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Jim Reid <[email-masked]>
Date: Sat, 6 Apr 2019 19:30:34 +0100

> On 6 Apr 2019, at 19:04, Watson Ladd <[email-masked]> wrote:
> 

Read this:
https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/consent/what-is-valid-consent

If you need further advice on GDPR, consult a Data Protection Authority or a lawyer who specialises in this field.

Note that the cast of thousands has been trimmed and this new thread is not cross-posted to other WG lists.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 6 Apr 2019 19:53:53 +0100

Hi Jim,

On 06/04/2019 19:30, Jim Reid wrote:
>> devices on your network. I also don't understand the GDRP issue
>> you raise: surely all DNS services have the same problems.
> 
> Read this: 

Too much text there for me sorry:-)

FWIW, I also don't get the GDPR angle here. If it's meant as
an issue of consent related to selection of DNS server, ISTM
more or less the same - if by picking an ISP I'm supposed to
have consented to the ISP's choice of recursive that same
argument seems to apply for a browser-chosen recursive since
the user chose the browser. (And I'd actually argue there is
no valid consent as to choice of recursive in either case,
since IMO a person cannot consent to use of something they
don't know exists, and people in general do not know that
DNS recursives exist.)

So can you explain the specific GDPR-related issue that you
think is relevant?

Thanks,
S.

>
>  If you need further advice on GDPR, consult a Data Protection
> Authority or a lawyer who specialises in this field.
> 
> _______________________________________________ Doh mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/doh
>

---

From: Brian Dickson <[email-masked]>
Date: Sat, 6 Apr 2019 12:40:58 -0700

Sent from my iPhone

> On Apr 6, 2019, at 11:53 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Jim,
> 

Stephen, 

It didn’t take me more than about 30 seconds of reading the linked article to get to the heart of the issue.

It has to do with whether something that requires consent is a necessary part of the service or transaction.

It has been clearly demonstrated that browsers do not have to provide DNS resolution (since they have not done so for about 25 years).

This means that requiring the user to use the browser’s selection of DNS resolver, and implementing a DNS forwarder in the browser, would not be covered by the general acceptance of the browser’s terms. In other words, an extra level of informed user consent would be required for GDPR, and not accepting that second set of terms should not prevent the use of the browser. Tying the two together would be a violation, at least as I understand it as explained by the link Jim provided.

>> Authority or a lawyer who specialises in this field.

+1

Brian

---

From: Watson Ladd <[email-masked]>
Date: Sat, 6 Apr 2019 12:51:27 -0700

> don't know exists, and people in general do not know that

There seems to be a lot of confusion about what actually shipped. I just
opened firefox. To use DoH I had to go to settings, change the settings,
and select either the default resolver or put in a free form URL. By
contrast joining a Wifi network on my phone changes my DNS settings with
absolutely no involvement of my part whatsoever.

I'm sure Mozilla has a general consul who has considered this carefully.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 6 Apr 2019 20:54:06 +0100

> I'm sure Mozilla has a general consul who has considered this carefully.

Yes. That was discussed on the list before.

I guess maybe I should've been clear that I was questioning
whether any GDPR issues were relevant, even if a browser did
ship with DoH turned on by default. (Which to be fair, mozilla
have said is something they'd like to do if they can.)

Cheers,
S.

---

From: Brian Dickson <[email-masked]>
Date: Sat, 6 Apr 2019 12:57:40 -0700

Resending

Sent from my iPhone

Stephen, 

+1

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 6 Apr 2019 20:58:35 +0100

Hiya,

On 06/04/2019 20:40, Brian Dickson wrote:
> It didn’t take me more than about 30 seconds of reading the linked
> article to get to the heart of the issue.

If that's the heart of the issue, then I remain unconvinced
that there is any real issue;-)

IOW, I'm still none the wiser as to what GDPR issue is
supposed to exist here.

> 
> It has to do with whether something that requires consent is a
> necessary part of the service or transaction.

Resolving DNS names is needed for a browser.

> It has been clearly demonstrated that browsers do not have to provide
> DNS resolution (since they have not done so for about 25 years).

Sure. But they are allowed innovate.

> This means that requiring the user to use the browser’s selection of
> DNS resolver, and implementing a DNS forwarder in the browser, would
> not be covered by the general acceptance of the browser’s terms. 

I don't believe the above is a good argument. First, "requiring
the user" isn't what's at issue, the situation of interest is
where DoH is on by default (which is not the current scenario).
Second, I've no idea what T&C's have to do with this - if there
is a GDPR issue, then T&C's that nobody reads can't avoid that.

S.

> In
> other words, an extra level of informed user consent would be
> required for GDPR, and not accepting that second set of terms should
> not prevent the use of the browser. Tying the two together would be a
> violation, at least as I understand it as explained by the link Jim
> provided.
> 
> 
>>>

---

From: Brian Dickson <[email-masked]>
Date: Sat, 6 Apr 2019 13:13:11 -0700

Sent from my iPhone

> On Apr 6, 2019, at 12:58 PM, Stephen Farrell <[email-masked]> wrote:
> 

I believe that is what the GDPR issue is.

You keep making this point for everyone else, not sure you realize that. 😀

In order for T&Cs to be applicable: they have to be read; the user has to understand them; and has to agree to them. (Those are themselves nontrivial UI issues.)

So, unless it is possible to explain DNS resolver choice so that an ordinary user can understand it, the user can’t give informed choice.  

This implies that any app bypassing the system choice of resolver (notwithstanding your concern over “choice”), at a minimum would need to attempt to do so, or clearly run afoul of GDPR. Whether that attempt clears the bar would likely be an issue for lawyers and courts.

The ISP issue isn’t relevant. Two wrongs don’t make a right, and bringing ISP DNS choice into this is deliberately conflating the issue, IMNSHO.

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 6 Apr 2019 22:23:23 +0100

On 06/04/2019 21:13, Brian Dickson wrote:
> The ISP issue isn’t relevant. Two wrongs don’t make a right, and
> bringing ISP DNS choice into this is deliberately conflating the
> issue, IMNSHO.
Ok, that's where we disagree then. I think both ISP or
browser choices of DNS recursive are the same in terms
of (lack of) real consent. That doesn't mean either or
both are "wrong" but I think it does mean that there's
no really new consent issue here.

(And btw, it's not great that you accuse me of "deliberately
conflating" - to do so would mean discussing this dishonestly,
and I am not doing that - it might be stylish of you to
retract that accusation.)

S.

---

From: Brian Dickson <[email-masked]>
Date: Sat, 6 Apr 2019 15:08:31 -0700

Sent from my iPhone

> On Apr 6, 2019, at 2:23 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

The distinction is similar vs new. They may be similar or even identical, but the browser one is very literally new.

Regardless of how the system choice of resolver/stub is done, it preexists as a/the mechanism for DNS resolution. Making changes to that choice (regardless of whether the previous choice was informed or explicit) IMHO requires additional consent, and that is what is new.

Lack of consent on the ISP does not justify, excuse, or convey implicit permission for an app to bypass the consent issue. 

Again, the above is MHO, but also, this consent problems is an issue that crosses over the line where leaving it unsettled by stating it is an issue we don’t agree to, does a disservice to the community of users of DNS.

> retract that accusation.)

It is possible to conflate things honestly, and 
I apologize if you or anyone else may inferred otherwise. I withdraw the “deliberately” from my previous statement, with apologies.

Brian

---

From: Adam Roach <[email-masked]>
Date: Sat, 6 Apr 2019 17:20:24 -0500

> Again, the above is MHO, but also, this consent problems is an issue that crosses over the line where leaving it unsettled by stating it is an issue we don’t agree to, does a disservice to the comm…

Engineers and lawyers practice rather different professions, both of 
which require extensive training and experience. When all the dust 
settles, it really doesn't matter what *we* think on these topics, in 
much the same way that it's not terribly important what the American Bar 
Association might think about TCP window size management. Jim and Watson 
both wisely deferred, at least in the abstract, to legal experts. I 
advise that this is the proper tactic.

/a

---

From: Brian Dickson <[email-masked]>
Date: Sat, 6 Apr 2019 16:10:22 -0700

On Sat, Apr 6, 2019 at 3:20 PM Adam Roach <[email-masked]> wrote:

> > Again, the above is MHO, but also, this consent problems is an issue
> that crosses over the line where leaving it unsettled by stating it is an
> issue we don’t agree to, does a disservice to the community of users of DNS.
>
>

Maybe, yes, and no. The problem in the above is the use of pronouns. :-)

But seriously, there are multiple variations on the issue, where the need
for lawyers, and/or the length and depth of those discussions, vary
considerably.

The possibilities I see include the following (and possibly others, such as
DoT):

   - DoH is off by default, and the DoH server field is empty (requires
   explicit user entry)
   - DoH is off by default, and the DoH server field is a drop-down list
   plus "other" (user entered), with no selected choice
   - DoH is off by default, and the DoH server field is a drop-down list or
   user-entry field, pre-populated with the system's configured DNS entries
   (static or DHCP-provided)
   - DoH is off by default, and the DoH server field is a drop-down list or
   user-entry field, pre-populated with something other than the system's
   configured DNS entries
   - DoH upgrade is on by default,  and the DoH server field is a drop-down
   list or user-entry field, pre-populated with the system's configured DNS
   entries (static or DHCP-provided)
   - DoH is on by default, and the DoH server field is a drop-down list or
   user-entry field, pre-populated with something other than the system's
   configured DNS entries

In the above cases where there is no pre-populated entry, or the system
server is what is pre-populated, I would expect a conversation with a
lawyer knowledgable in the field to be very brief.
"The only way the user can change their DNS resolver choice is by actively
typing text or doing a list-select? Okay, sounds good."
"Turning on DoH doesn't change the DNS provider? Great."
"Can the user force the resolver operator to use DoH, or does the operator
also have to enable DoH? Has to enable it? Great."

For the other cases, I agree with Jim and Watson. I wanted to make the
distinction above, since those are apples and oranges (rooted in changing
the DNS provider, irrespective of anything else).

Brian

---

From: Christian Huitema <[email-masked]>
Date: Sat, 6 Apr 2019 16:39:18 -0700

> On Apr 6, 2019, at 4:10 PM, Brian Dickson <[email-masked]> wrote:
> 
> For the other cases, I agree with Jim and Watson. I wanted to make the distinction above, since those are apples and oranges (rooted in changing the DNS provider, irrespective of anything else).

As a general principle, we could certainly agree that the flow of DNS requests provides lots of sensitive information about the usage of the device, including means of identifying the user. So yes, the choice of a specific resolver has important consequences on the user's privacy. As much as possible, the user should be informed of the consequences and able to choose.

But then, the choice of staying with the default network configuration also has consequences. And it has different consequences on different networks. So ideally the user should be informed of these consequences too and given a choice. 

-- Christian Huitema

---

From: Vittorio Bertola <[email-masked]>
Date: Sun, 7 Apr 2019 10:43:05 +0200 (CEST)

> Il 7 aprile 2019 alle 0.20 Adam Roach <[email-masked]> ha scritto:
> 
> Jim and Watson 

First of all, I agree: we are not lawyers, and even if we were, GDPR sets the basic principles but its application to concrete situations is often arguable, and clarity only appears when a competent data protection authority examines a specific case and comes to a decision, and even then, the decision could still be challenged and go all the way up to the highest national and European courts.

This said, since I am also one of the people that raised the GDPR issue, let me provide a general view.

GDPR (article 6.1: see http://www.privacy-regulation.eu/en/article-6-lawfulness-of-processing-GDPR.htm ) requires that any processing of personal information related to a European citizen happens only after the citizen has provided explicit and informed consent (as defined in article 4.11 http://www.privacy-regulation.eu/en/article-4-definitions-GDPR.htm#a4_nr11 ), except for a number of situations in which consent is not required (legal obligations, life at stake, "legitimate interest"...). 

It is hard to see how the processing of DNS queries could fall in any of the non-consensual cases, though indeed the DoH operator could look for one of these exceptions, or try to argue that DNS queries are not personal information. But if we assume that consent is necessary, then the operator needs to acquire it before starting to process any personal information.

When someone signs up for Internet access with an ISP, the ISP gets them to sign a contract, which, in Europe, definitely includes privacy clauses; that is the place where the user provides explicit and informed consent to data processing, including for the DNS.

When the user connects to a random wifi network, usually they get to go through a captive portal which requires them to accept terms and conditions, which, again, include the consent for data processing.

When the user changes the recursor manually in a configuration entry (even today, even with standard DNS), no terms are shown and no consent is asked, but there is an explicit action by the user; so the operator can argue that the consent was explicit, though not informed ("informed" in GDPR terms requires the showing of certain information, such as the name and contacts of the entity that treats the data). So this is IMHO not GDPR-compliant, but since there has been no controversy and there is at least the most important half of the consensus (the "explicit" part, i.e. "specific, freely given, unambiguous" in GDPR terms), no one complained about this yet.

If the application changes the name server by default, then the situation is worse, because the consent is neither explicit nor informed. Installing the application cannot be taken as "specific, freely given, unambiguous" consent, especially if the application never processed DNS data before and so this cannot be expected by the user. So IMHO this is definitely not GDPR compliant.

This however is not a problem that cannot be solved; it will be enough for the application to show a more detailed, GDPR-compliant request for consent when it wants to change the recursor and use one for which the user has not provided consent yet, rather than just tell the user "we are giving you better DNS, ok?". And I guess that Mozilla's lawyers are aware of this and we will see this happening if they actually decide to turn DoH on by default in Europe.

Still, apart from the legal details, the principle underlying the GDPR consent requirements is that if you want to claim that you do something on behalf of the user, you have to ask the user properly. This is the objection that led several people to raise this point in the discussion, and I think it is a valid objection even if we are not lawyers. But, as I said, there are ways to address it.

Ciao,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Jim Reid <[email-masked]>
Date: Sun, 7 Apr 2019 14:33:56 +0100

> On 6 Apr 2019, at 19:53, Stephen Farrell <[email-masked]> wrote:
> 
> an issue of consent related to selection of DNS server....
> 

Hi Stephen. When has relevance ever mattered on an IETF list? :-)

From a strict protocol design perspective, GDPR issues probably never matter for the IETF. After all the IETF doesn’t exist so it can’t be sued or prosecuted. GDPR does however have an impact on how IETF protocols get used and deployed. Sometimes that might impact need to be assessed in an IETF setting, just like how IETF docs are expected to have security and human rights considerations these days.

GDPR is already covered in the T&Cs between an ISP and the end user. Or should be. [You’ve probably been bombarded by GDPR tweaks to the T&Cs for your bank, utility providers, etc.] When DoH is used, this is likely to introduce third parties - the DoH service provider and a DoH client. GDPR compliance will be an issue for them, particularly the requirement to get meaningful consent from the end user. How these third parties do that is unlikely to be a topic for the IETF.

That said, I think it’s important that this WG is at least aware of these problems and documents them somehow. ie It produces an RFC which somewhere says something like "If you’re responsible for a DoH platform, make sure you’ve sorted out the GDPR concerns”.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 7 Apr 2019 14:39:17 +0100

Hiya,

On 07/04/2019 09:43, Vittorio Bertola wrote:
> When someone signs up for Internet access with an ISP, the ISP gets
> them to sign a contract, which, in Europe, definitely includes
> privacy clauses; that is the place where the user provides explicit
> and informed consent to data processing, including for the DNS.
I just checked my ISP account's privacy policy and "contract
options." There is no mention of DNS at all. I didn't go chase
down the actual contract text but am happy to bet a beer that
DNS query privacy won't be mentioned there either.

So while I do agree that the centralising aspects of some kinds
of DNS deployment are a concern, I see no reason why that's any
different in real privacy or GDPR terms from the current
situation.

That said, it's maybe a hopeful sign that at least we're starting
to think about having operators publish policies as to their
handling DNS query info. If the mozilla/CF DoH setup prods DNS
operators to do that, that'll be good. (Do we have any examples
of DNS operators publishing such policy information for Do53?
Be good to see some if they exist.)

S.

---

From: Christian Huitema <[email-masked]>
Date: Sun, 7 Apr 2019 06:45:35 -0700

> On Apr 7, 2019, at 6:33 AM, Jim Reid <[email-masked]> wrote:
> 

How is that specific to DNS over HTTPS, compared to setting the default provider to 8.8.8.8, or using DNS over TLS?

Also, I seem that I am hearing two contradictory statements. On one hand, I hear that using 3rd party resolvers would do economic harm to the ISP and prevent them from monetizing the DNS metadata. On the other hand, I hear that switching to a user chosen DNS provider would affect the user privacy, even when that provider publicly states that it won't be collecting user specific meta data. Somehow, the ISP monetizing privacy sensitive data would be GDPR compliant, while the third party respecting the user privacy would not be. Really?

-- Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 7 Apr 2019 15:07:04 +0100

Hiya,

On 07/04/2019 14:33, Jim Reid wrote:
>> FWIW, I also don't get the GDPR angle here. If it's meant as an
>> issue of consent related to selection of DNS server....
>> 
>> So can you explain the specific GDPR-related issue that you think
>> is relevant?
> 

Either never or always, depending who you're arguing with:-)

> 
> From a strict protocol design perspective, GDPR issues probably never
> matter for the IETF. After all the IETF doesn’t exist so it can’t be
> sued or prosecuted. 

Didn't you notice the LLC thing? :-)

> GDPR does however have an impact on how IETF
> protocols get used and deployed. Sometimes that might impact need to
> be assessed in an IETF setting, just like how IETF docs are expected
> to have security and human rights considerations these days.

I agree that we need to consider GDPR issues, where they exist.
The question I'm posing here is whether there are any new GDPR
issues caused by DoT/DoH and I'm just not seeing them. I can
totally accept that there are privacy/GDPR issues in providing
DNS service that have been largely or totally ignored until
very recently.

(Security considerations btw are needed in drafts, but human
rights considerations are not a requirement, and nor should they
be IMO.)

> 
> GDPR is already covered in the T&Cs between an ISP and the end user.
> Or should be.

As far as DNS query privacy is concerned, that doesn't appear
to be explicitly mentioned by my ISP. Maybe that's an outlier
but I'd be surprised. So I don't accept that "already covered"
is correct, for DNS query privacy.

(Separately, I also don't accept that one can get informed
consent from a person who doesn't understand the question being
asked. So from my POV, all this "click to accept" crap is
just crap and no more. I do realise that some lawyers likely
disagree.)

> [You’ve probably been bombarded by GDPR tweaks to the
> T&Cs for your bank, utility providers, etc.] When DoH is used, this
> is likely to introduce third parties - the DoH service provider and a
> DoH client. 

An ISP could as easily be forwarding all my queries to a quad-N
service, and/or be providing a sample-point for passive DNS, so
ISTM these aren't really new issues at all. (WRT passive DNS, even
if no stub IP addresses are provided, I suspect one could identify
or re-identify based on patterns of QNAMEs and timing.)

> GDPR compliance will be an issue for them, particularly
> the requirement to get meaningful consent from the end user. How
> these third parties do that is unlikely to be a topic for the IETF.

Except people keep raising this as an issue, but without being
specific enough for me at least to understand if there is or is
not any effect on protocols.

From the above, it sounds like you agree there is no effect on
the DoH WG. If that's right then we should accept that there is
no GDPR discussion to have here.

> 
> That said, I think it’s important that this WG is at least aware of
> these problems and documents them somehow. ie It produces an RFC
> which somewhere says something like "If you’re responsible for a DoH
> platform, make sure you’ve sorted out the GDPR concerns”. 

I think that's way too vague to be useful in an I-D. An I-D that
had such text could be described as possibly baselessly generating
FUD, which'd be bad.

I think [1] could provide a fine place to discuss these issues,
but perhaps it needs a permutation applied to the title so that
becomes "Privacy Recommendations for DNS Service Operators." I'm
not sure if we'd find rough consensus to try tackle all the issues
that'd raise though.

S.

[1] https://tools.ietf.org/html/draft-ietf-dprive-bcp-op

---

From: Adam Roach <[email-masked]>
Date: Sun, 7 Apr 2019 16:46:23 +0200

On 4/7/19 10:43, Vittorio Bertola wrote:
> This is the objection that led several people to raise this point in the discussion, and I think it is a valid objection even if we are not lawyers.

There was context to my reply: Stephen had provided his rationale for 
why he thought that Brian's interpretation of the GDPR was not 
necessarily correct. Brian responded by saying that this disagreement in 
the IETF over GDPR consent applicability was a disservice to users.

The point of my response is that it's really not: even if the IETF were 
to form a consensus position on the topic of GDPR applicability, it 
wouldn't be worth the paper it's written on. As a technical standards 
body, we're just not the experts here.

To be clear, I think we should and do take into consideration issues of 
user privacy and agency and several closely related topics. What I'm 
objecting to is the attempt to parse applicability of finer points of 
the GDPR: these are legal issues, and we are not lawyers. The line I'm 
drawing here is roughly the one between Natural Law and Positive Law.

I would advise that anyone who wants to discuss the Natural Law 
implications do so in a thread with a different subject line, and that 
those who want to discuss GDPR applicability do so in a legal forum 
rather than a technical one.

/a

---

From: Adam Roach <[email-masked]>
Date: Sun, 7 Apr 2019 09:55:59 -0500

On 4/7/19 15:33, Jim Reid wrote:
> That said, I think it’s important that this WG is at least aware of these problems and documents them somehow.

Are we going to do a survey of privacy regulations in the other 167 
countries also? How frequently do you see us updating such documentation?

/a

---

From: Jim Reid <[email-masked]>
Date: Sun, 7 Apr 2019 16:52:56 +0100

On 7 Apr 2019, at 15:55, Adam Roach <[email-masked]> wrote:
> Are we going to do a survey of privacy regulations in the other 167 countries also?

IMO no. That’s clearly impractical. Even if the IETF had the appropriate legal expertise. Which it doesn’t.

I think we should approach these issues on a case-by-case basis when they emerge and are brought to the IETF’s attention. EU regulations might need closer consideration because: (a) they tend to be at the vanguard on data protection/privacy issues; (b) other countries often cut & paste (pretty much) EU data protection/privacy stuff into their own legislation.

> How frequently do you see us updating such documentation?

As and when the need arises? Like we do with every RFC. :-)

The sort of documentation I had in mind would be something like: “Here’s what we as protocol experts think the impact of GDPR (or whatever) might be on deployment of protocol X: .... This is not legal advice. For definitive information, consult your DPA and/or suitably qualified legal advisors. The IETF hopes the info above may be useful input to those discussions that need to take place elsewhere.”.

---

From: Jim Reid <[email-masked]>
Date: Sun, 7 Apr 2019 17:28:54 +0100

On 7 Apr 2019, at 15:07, Stephen Farrell <[email-masked]> wrote:
> the DoH WG.

I didn’t say that Stephen.

IMO GDPR has no impact on the DoH *protocol*. GDPR does have an impact on how that protocol gets used and deployed. This needs to be discussed at the IETF and the obvious home for that discussion seems to be the DoH WG - at least for now. The WG is explicitly chartered to work on DoH’s security and privacy issues. If not there, then where?

You said you "agree that we need to consider GDPR issues, where they exist” and seem to be saying that there are no new GDPR issues caused by DoT/DoH. Well, the issues are new. Sort of. Although they’ve been around for a while, as you said they “have been largely or totally ignored until very recently”. Maybe they should have been discussed earlier. But that earlier non-discussion doesn’t seem to me to be a valid reason for dismissing these concerns now that they have been raised. YMMV.

---

From: Jim Reid <[email-masked]>
Date: Sun, 7 Apr 2019 17:34:58 +0100

> On 7 Apr 2019, at 14:45, Christian Huitema <[email-masked]> wrote:
> 

Because we’re just talking here about DoH deployment Christian. :-)

As you rightly point out the self-same issues arise for 8.8.8.8 (other anycast providers are available) and DoT. These are for consideration by the dnsop and dprive WGs respectively. Maybe.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 7 Apr 2019 18:09:01 +0100

Hiya,

On 07/04/2019 17:28, Jim Reid wrote:
>> From the above, it sounds like you agree there is no effect on the 
>> DoH WG.
> 

Sure, but I figured it might follow from what you did say.
(That said, your mail to Christian clarifies a bit for me
where we may disagree here.)

> 
> IMO GDPR has no impact on the DoH *protocol*.

Agreed.

> GDPR does have an impact on how that protocol gets used and deployed.

True, but I disagree:-)

Where I disagree is I don't think it makes any sense to try
analyse the privacy or GDPR issues of DoH in isolation (that's
sort-of been done and the DoH-specific issues only relate to
the HTTP framing and how that provides more tracking tooling if
a service provider wants to try use those and if a client isn't
a bit more strict than a typical web UA). So those DoH-specific
issues are really just a footnote to the main concerns which
mostly relate to service selection, centralisation and perhaps
transparency.

OTOH, it makes total sense to do such analysis for the DNS more
generally, perhaps splitting out the stub/recursive scenario as was
done when we started DPRIVE.

> This needs to be discussed at the IETF and the obvious home for that
> discussion seems to be the DoH WG - at least for now. The WG is
> explicitly chartered to work on DoH’s security and privacy issues. If
> not there, then where?

That's one for the IESG, and after Prague they do know for sure
that that's one for them. I'm hoping they do that bit of steering
soonish.

> 
> You said you "agree that we need to consider GDPR issues, where they 
> exist” and seem to be saying that there are no new GDPR issues
> caused by DoT/DoH. Well, the issues are new. Sort of. Although
> they’ve been around for a while, as you said they “have been largely
> or totally ignored until very recently”. Maybe they should have been
> discussed earlier. But that earlier non-discussion doesn’t seem to me
> to be a valid reason for dismissing these concerns now that they have
> been raised. YMMV.

Mostly agree, with two caveats:

- I think the newness here is really driven by other concerns
with the kind of change exemplified by the mozilla/CF setup, and
is not solely/primarily driven by concerns with privacy/GDPR,
where I continue to maintain that there aren't really new issues.

- I am not "dismissing" privacy/GDPR concerns - I'm claiming that
they are a) not new b) not specific to DoH c) equally apply to
services using Do53 as well as DoT and lastly d) are only worth
analysing in that broader context.

Bottom line is I think we're mostly in agreement about the meat
of the issues here, but seem to still disagree about the best
venue and scope for discussion. And that last bit is the IESG's
to fix, so we don't have to:-)

Cheers,
S.

---

From: Vittorio Bertola <[email-masked]>
Date: Sun, 7 Apr 2019 19:23:13 +0200 (CEST)

>     Il 7 aprile 2019 alle 16.07 Stephen Farrell < [email-masked] mailto:[email-masked] > ha scritto:
> 
I suspect that your ISP has a general consent request in their contract or privacy annex, in which they ask you for consent to treat any personal information that you provide or generate in the context of the Internet access service you are acquiring, for the purpose of what is necessary to provide you such access. That would cover treating DNS queries for giving you back IP addresses, though it would not cover any monetization of them, unless they also ask you for consent for the purpose of targeted advertising or other types of processing (except possibly any processing connected with network security, as that would likely fall under the exceptions to consent listed in the GDPR, as a legitimate interest and/or as necessary to comply with cybersecurity laws).

>     just crap and no more. I do realise that some lawyers likely
One positive outcome of this discussion could be a collective attempt to define standard terminology and ways to communicate DNS operator behaviour and policies to final users. It would be great to see all recursor operators, ISP or OTT, communicate their DNS data policies clearly to final users, and uniformity would facilitate user education a lot.

>     not any effect on protocols.
I think this was raised in the context of the discussion of DoH deployment policies and of the drafts that were meant to formalize the concerns and discuss best practices, and that, as I understand, are now frozen (hopefully not for long) waiting for the IESG to tell us if and where they can be discussed.

Ciao,

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 7 Apr 2019 18:53:47 +0100

Hiya,

On 07/04/2019 18:23, Vittorio Bertola wrote:
> I suspect that your ISP has a general consent request in their
> contract or privacy annex, in which they ask you for consent to treat
> any personal information that you provide or generate in the context
> of the Internet access service you are acquiring, for the purpose of
> what is necessary to provide you such access. That would cover
> treating DNS queries for giving you back IP addresses, though it
> would not cover any monetization of them, unless they also ask you
> for consent for the purpose of targeted advertising or other types of
> processing (except possibly any processing connected with network
> security, as that would likely fall under the exceptions to consent
> listed in the GDPR, as a legitimate interest and/or as necessary to
> comply with cybersecurity laws).
> 
> However, this would mean that DNS is already covered in legal
> compliance terms, but less so in terms of specific communication of
> what the operator does with your queries, and I agree with you that
> this is a different problem than legal compliance, 

I read their privacy policy and a bunch of other information
they make easily available and am none the wiser as to what
they do or don't do with DNS data. I'm pretty sure that nobody
who didn't know that DNS exists could appreciate these issues
based on the text that ISP makes available.

(Maybe I'll ask them about it for a laugh, but that tends to
be very time consuming with little payoff. I'll see how bored
I get in the next few days:-)

> though I disagree
> that it cannot be solved:

I never said there were unsolveable problems here.

I said that DoH doesn't create any new privacy/GDPR problems.
The interesting privacy/GDPR problems related to DNS aren't
DoH specific. Those can definitely be analysed objectively
(i.e. without trying to make DoH seem bad:-) and we could
document the results so that operators could more easily
make clear statements about this (or be called out for not
doing so).

I also said that I think most of how the IT business treats
so-called "consent" is rubbish. That could be fixed in theory
if we had an epidemic of honesty, so while the solution is
utterly obvious, I'm not at all hopeful there;-)

Cheers,
S.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 7 Apr 2019 12:16:17 -0700

william manning wrote on 2019-04-05 09:43:
> Every now and then, Paul Vixie and I are in complete harmony.  

i am in no way concerned about that.

> In my 
> presents to our security posture.  ...

sadly, there are some here, and many elsewhere, who consider that you 
already had that burden, because the opacity of HTTPS especially with 
TLS 1.3 and encrypted SNI, means that the exfiltration risk preexisted, 
and was not made worse by DOH.

those considerations are naive and incorrect. however, it's necessary to 
explicitly re-dismiss them every time you mention the imposed costs of 
DOH. it is the _standardization_ aspect of DOH, and the possibility of 
encountering it inside HTTPS TCP IP DST addresses that did not offer it 
pre-standardization, that imposes the _new_ exfiltration and other risks.

> This genie has not signed BAA or supplier agreement with us and we will 
> not allow it to dictate our business processes or affect our liability 
> without the DOH enabler shouldering fiscal and legal exposure when DOH 
> is shown to be the culprit in exposure of private data.  I can't see how 
> DOH is going to pass GDRP muster inside the EU either, but that is for 
> others to debate.  I have told my GDRP affected counterparts about the 
> privacy risks with DOH deployment.

i hear your pain.

-- 
P Vixie

---

From: S Moonesamy <[email-masked]>
Date: Sun, 07 Apr 2019 05:29:42 -0700

Hello,
At 01:43 AM 07-04-2019, Vittorio Bertola wrote:
>GDPR (article 6.1: see 
>http://www.privacy-regulation.eu/en/article-6-lawfulness-of-processing-GDPR.htm 
>) requires that any processing of personal information related to a 
>European citizen happens only after the citizen has provided 
>explicit and informed consent (as defined in article 4.11 
>http://www.privacy-regulation.eu/en/article-4-definitions-GDPR.htm#a4_nr11 
>), except for a number of situations in which consent is not 
>required (legal obligations, life at stake, "legitimate interest"...).

>and informed consent to data processing, including for the DNS.

There is a privacy clause in a contract with a service provider when 
the latter has to comply with the data protection regulations of the 
country in which it is operating.  The contract I am familiar with 
mentions the law which applies instead of the E.U. General Data 
Protection Regulation (GDPR).  It is up to the "data controller" and 
"data processor" to assess whether informed consent is needed.

The data protection angle of the DNS over HTTPS case is 
debatable.  It could be argued that DNS over HTTPS could be used for 
privacy-unfriendly purposes.  There might also be a dissonance with 
respect to BCP 188.

Regards,
S. Moonesamy

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 9 Apr 2019 21:17:22 +0000

> As you rightly point out the self-same issues arise for 8.8.8.8 (other anycast providers are available) and DoT. 

[JL] The key difference is that the user was taking action to configure 8.8.8.8. In the DoH case, if you have software make this determination on behalf of the user, then that seems to be the key difference and what potentially makes GDPR and similar regulations in other countries operable. *I don't think we need to keep discussing the issue though; the issue's been raised and parties can come to their own legal assessments of what may or may not be required in a given legal jurisdiction.*

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 9 Apr 2019 21:30:12 +0000

On 4/7/19, 9:46 AM, "Doh on behalf of Christian Huitema" <[email-masked] on behalf of [email-masked]> wrote:
> On one hand, I hear that using 3rd party resolvers would do economic harm to the ISP and prevent them from monetizing the DNS metadata. 

[JL] The issues I and others outlined didn't include that issue, and it doesn’t from my perspective seem defensible. Rather, countering this behaviour by some ISPs was offered as one of the justifications motivating centralised DoH.

> On the other hand, I hear that switching to a user chosen DNS provider would affect the user privacy, even when that provider publicly states that it won't be collecting user specific meta data. 

[JL] I think there's still a bit more nuance here (and maybe appropriate to the ADD list), as one of the issues noted at the side meeting was that these policies address the DNS query/response layer but not necessarily the HTTP layer within which that is contained. So that may merit further exploration.