Subject: [Add] Best practice on HTTP cookies in DoH

From: <[email-masked]>
Date: Wed, 18 Dec 2019 14:01:55 +0000

I would like to ask for your opinion as to when cookies should be permitted in DoH requests, and when not. From previous messages I'm aware that both Firefox and Chrome are intended to never send DoH cookies, but these are only two. It feels like we should have a general statement on the correct use of cookies, as any implementation is likely to re-use an HTTP library they already possess.

RFC8484 has this to say on the subject:

   HTTP's feature set can also be used for identification and tracking
   in a number of different ways.  For example, Authentication request
   header fields explicitly identify profiles in use, and HTTP cookies
   are designed as an explicit state-tracking mechanism between the
   client and serving site and often are used as an authentication
   mechanism.

   Determining whether or not a DoH implementation requires HTTP cookie
   [RFC6265] support is particularly important because HTTP cookies are
   the primary state tracking mechanism in HTTP.  HTTP cookies SHOULD
   NOT be accepted by DOH clients unless they are explicitly required by
   a use case.

My reading of this, is it says clients should not accept "Set-Cookie" as part of a DoH response, but says nothing about whether clients should send "Cookie" headers that they have previously learned for the relevant domain. If my configured DoH server is doh.example.com, and in my cookie database I have example.com, should the DoH client disregard that cookie?

My impression is that unless there is a good reason to use one, the expected behaviour should be:

  *   Clients SHOULD NOT send cookies on DoH requests
  *   Servers SHOULD discard any cookies they receive on DoH requests
  *   Servers SHOULD NOT set cookies in DoH responses
  *   Clients SHOULD NOT accept cookies in DoH responses (already stated in RFC8484)

Are you aware of a use case that would require cookies? For example would enterprises need it, or do they already have better mechanisms?

Thanks,
Chris

---

From: <[email-masked]>
Date: Wed, 18 Dec 2019 14:23:27 +0000

By the way in case it's not clear, I'm asking purely about handling of HTTP cookies (RFC6265), not DNS cookies (RFC7873), or any other kind .

---

From: "John Levine" <[email-masked]>
Date: 18 Dec 2019 11:14:00 -0500

>Are you aware of a use case that would require cookies? For example would enterprises need it, or do they already have better mechanisms?

If I were running a DoH server that was not open to the public,
cookies would be a cheap way to verify that a client was authorized.

There are alternatives like client certificates but they're a lot
harder to set up and manage.

R's,
John

---

From: Eric Orth <[email-masked]>
Date: Wed, 18 Dec 2019 11:50:33 -0500

Right.  You can come up with lots of special cases that can make use of
cookies and DoH, so I think the spec took the right approach with the
"unless they are explicitly required by a use case" language.  I agree that
in the general standard case (with the same special case caveat) it would
be best if neither the client nor server were ever handling cookies.

For clarity, Chrome's designed DoH cookie behavior: Chrome never sends or
accepts cookies in DoH requests or responses, and the DoH code will not
share sockets with any other code that sends or accepts cookies.

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 18 Dec 2019 19:22:09 +0100 (CET)

Il 18/12/2019 17:50 Eric Orth <ericorth=[email-masked]> ha scritto:

Right.  You can come up with lots of special cases that can make use of cookies and DoH, so I think the spec took the right approach with the "unless they are explicitly required by a use case" language.  I agree that in the general standard case (with the same special case caveat) it would be best if neither the client nor server were ever handling cookies.

For clarity, Chrome's designed DoH cookie behavior: Chrome never sends or accepts cookies in DoH requests or responses, and the DoH code will not share sockets with any other code that sends or accepts cookies.

I am thinking of a use case in which an operator (e.g. an ISP or a corporate network administrator) provides a DoH server that is also meant to be used by its users, but only by them, when roaming onto public networks. In this case, some ongoing authentication of the DoH requests should happen, perhaps through some kind of initial "login" procedure followed by a tracking mechanism. Would this be a use case in which clients would actually have to make use of cookies? What would be the preferred way to implement something like this, and would browsers support it?

--

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

---

From: Eric Orth <[email-masked]>
Date: Wed, 18 Dec 2019 13:55:27 -0500

On Wed, Dec 18, 2019 at 1:22 PM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> I am thinking of a use case in which an operator (e.g. an ISP or a
> corporate network administrator) provides a DoH server that is also meant
> to be used by its users, but only by them, when roaming onto public
> networks. In this case, some ongoing authentication of the DoH requests
> should happen, perhaps through some kind of initial "login" procedure
> followed by a tracking mechanism. Would this be a use case in which clients
> would actually have to make use of cookies? What would be the preferred way
> to implement something like this, and would browsers support it?
>

Not something Chrome could commit to supporting today, as nothing like that
is in our current plans.  But certainly something worth exploring and
standardizing if this turns into a strong usecase.

I imagine it would be something the device user/admin would have to opt
into via UI or policy.  And then, yes, cookies may make the most sense as
the tracking mechanism, but there may be other options as well.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 18 Dec 2019 17:20:01 -0500

On Wed, Dec 18, 2019 at 9:02 AM <[email-masked]> wrote:

> My reading of this, is it says clients should not accept “Set-Cookie” as
> part of a DoH response, but says nothing about whether clients should send “
> Cookie” headers that they have previously learned for the relevant
> domain. If my configured DoH server is doh.example.com, and in my cookie
> database I have example.com, should the DoH client disregard that cookie?
>
>
>

A clearer version of the text would say SHOULD NOT be accepted or sent by
DOH clients ... the text is envisioning that a DOH client doesn't share a
cookie DB with a non-DoH client (and therefore not accepting is akin to not
sending).. its a worthy bis item imo. Your example using the horrid eTLD
rules of cookies is completely valid, but so is a simpler example of
another same origin exchange that simply isn't using DoH. afaict what is
widely implemented is "accepted or sent".

Are you aware of a use case that would require cookies?

Probably tokens for use of non-public servers.

---

From: <[email-masked]>
Date: Thu, 19 Dec 2019 18:49:28 +0000

Thanks for all the excellent responses so far.

Alex wrote:

  *   Servers SHOULD use dedicated domains that cannot potentially share cookies with web applications

This of course carries a downside, since we are asking users to place their trust in a particular provider. Using current examples, to my brain cloudflare-dns.com appears less trustworthy than cloudflare.com. The former has been in existence since 2018, the latter since 2009. It’s not just a matter of longevity, but also the ability of anyone with ill intent to register a domain that is broadly similar. (I notice cloudflare--dns.com is available.)

Rob wrote:

All of these additional requirements are redundant, and are implied by the requirement stated in RFC8484 and the security considerations of HTTP itself (I looked at RFC7231).

Rob please could you elaborate, as I’m unable to follow your logic. Where in RFC7231 does it imply the first three bullet points, given the fourth?

Patrick wrote:

A clearer version of the text would say SHOULD NOT be accepted or sent by DOH clients ... the text is envisioning that a DOH client doesn't share a cookie DB with a non-DoH client (and therefore not accepting is akin to not sending).. its a worthy bis item imo.

Yes it would seem sensible for it to have no access to the normal browser cookie DB. This could reside in a best practice statement, if it’s seen as difficult to do a 8484bis.

A separate DoH cookie DB would of course normally be entirely empty, except for this (from both Patrick and John):

tokens for use of non-public servers.

For which we have Vittorio’s more described case:

I am thinking of a use case in which an operator (e.g. an ISP or a corporate network administrator) provides a DoH server that is also meant to be used by its users, but only by them, when roaming onto public networks.

To which Eric said:
Not something Chrome could commit to supporting today, as nothing like that is in our current plans.  But certainly something worth exploring and standardizing if this turns into a strong usecase.

I agree that DoH implementations should be cookie-free as far as possible, right now. In fact I was trying to strengthen this situation, as I thought the RFC wording left a lot of room for accidental cookie use. But I would need to spend more time thinking about the best authorization protocol for Vittorio’s case.

Chris

---

From: Rob Sayre <[email-masked]>
Date: Thu, 19 Dec 2019 11:17:48 -0800

On Thu, Dec 19, 2019 at 10:49 AM <[email-masked]> wrote:

> Rob wrote:
>
>
>
> *All of these additional requirements are redundant, and are implied by
> the requirement stated in RFC8484 and the security considerations of HTTP
> itself (I looked at RFC7231).*
>
>
>
> Rob please could you elaborate, as I’m unable to follow your logic. Where
> in RFC7231 does it imply the first three bullet points, given the fourth?
>

There are two relevant sections:

1) 5.4.  Authentication Credentials

   Two header fields are used for carrying authentication credentials,
   as defined in [RFC7235].  Note that various custom mechanisms for
   user authentication use the Cookie header field for this purpose, as
   defined in [RFC6265].

The "explicitly required by a use case" language in RFC 8484 seems to cover
this concern (related to what Vittorio brought up).

2) 9.7.  Browser Fingerprinting

   ... Cookie header fields are deliberately
   designed to enable re-identification, so fingerprinting concerns only
   apply to situations where cookies are disabled or restricted by the
   user agent's configuration. ...

To further belabor the point, RFC6265 defines the Cookie header as follows:

  "The user agent sends stored cookies to the origin server in the Cookie
header."

RFC 8484 says clients shouldn't accept them, so it shouldn't matter if
servers send them, and, if Set-Cookie headers are not stored, a
corresponding Cookie header can't be sent.

That leaves "Servers SHOULD discard any cookies they receive on DoH
requests" which does not seem to add any new interoperability requirements.

thanks,
Rob

---

From: Andrew Campling <[email-masked]>
Date: Thu, 19 Dec 2019 22:57:16 +0000

> On Wed, Dec 18, 2019 at 18:55 Eric Orth <[email-masked]> wrote:

>> On Wed, Dec 18, 2019 at 1:22 PM Vittorio Bertola <vittorio.bertola=[email-masked]<mailto:[email-masked]>> wrote:
>> I am thinking of a use case in which an operator (e.g. an ISP or a corporate network administrator) provides a DoH server
>> that is also meant to be used by its users, but only by them, when roaming onto public networks. In this case, some ongoing
>> authentication of the DoH requests should happen, perhaps through some kind of initial "login" procedure followed by a
>> tracking mechanism. Would this be a use case in which clients would actually have to make use of cookies? What would
>> be the preferred way to implement something like this, and would browsers support it?

> I imagine it would be something the device user/admin would have to opt into via UI or policy.  And then, yes, cookies may make the most sense as the tracking mechanism, but there may be other options as well.

I think the worry is that DoH is promoted as being a privacy-enhancing standard.  When tracking mechanisms are involved, events over the last few years tell us that some developers will find the temptation of monetisation irresistible and will exploit the availability of those mechanisms accordingly, as could others with more sinister intent.  I would therefore suggest that well-behaved clients and DoH servers should avoid the use of cookies and should take steps to disable their use by others too.

NB For clarity, I’m not suggesting that such malpractice would apply to the browser developers, simply that less scrupulous developers would exploit the situation noting the many privacy intrusions in recent years.

Andrew

---

From: <[email-masked]>
Date: Mon, 23 Dec 2019 12:45:25 +0000

Rob wrote:
  "The user agent sends stored cookies to the origin server in the Cookie header."
RFC 8484 says clients shouldn't accept them, so it shouldn't matter if servers send them, and, if Set-Cookie headers are not stored, a corresponding Cookie header can't be sent.

Rob, please consider this scenario:

  1.  Client browser software has been written without considering that DoH client requires its own separate cookie DB, e.g. because this is not a requirement of 8484.
  2.  Client browser visits www.example.com.
  3.  www.example.com sets a cookie for example.com.
  4.  Client browser learns about dns.example.com/dns-query.
  5.  Client browser makes a query to dns.example.com, and uses default HTTP client code, which inserts the cookie from step 3.

Firefox and Chrome won’t do the above, but in future we could be looking at hundreds of different DoH client implementations.

This feels like a genuine risk which we should make an effort to try to prevent somehow. Do you agree?

Thanks
Chris

---

From: "John Levine" <[email-masked]>
Date: 23 Dec 2019 09:49:42 -0500

>This feels like a genuine risk which we should make an effort to try to prevent somehow. Do you agree?

No.  As we have learned far too many times, you can't fix inept by
making rules, and you also don't know what everyone's security model
is.

If someons is using DoH to talk to a server you don't trust, then you
should write your client so it doesn't leak info it doesn't need to.
If it does, that's a bug.  (This begs the question of why you're using
a DoH server you don't trust, but whatever.)

On the other hand, an IoT device or a mobile app that uses a server
run by the vendor of the device or app presumably does trust the
server since they're all under the same control, so whatever the
client sends isn't a problem.

I really don't think there's anything to do here beyond what's in 8484.

R's,
John

---

From: Andrew Campling <[email-masked]>
Date: Mon, 23 Dec 2019 16:44:20 +0000

On 23 December 2019 14:50, John Levine <[email-masked]> wrote:

> On the other hand, an IoT device or a mobile app that uses a server run by the vendor 
> of the device or app presumably does trust the server since they're all under the same 
> control, so whatever the client sends isn't a problem.

In the above case we may wonder whether the user, as opposed to the device or app vendor, trusts the server and whether the server's policies are consistent with those of the user.  I think it would be a real problem if apps or devices made use of a protocol's privacy characteristics to communicate in ways that compromise the user's security without their knowledge or consent.  Anything that can be done to prevent this or at least make it more difficult would seem to me to be desirable.  

Andrew

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Dec 2019 16:52:08 +0000

> In the above case we may wonder whether the user, as opposed to the device or app vendor, trusts the server and whether the server's policies are consistent with those of the user.  I think it woul…

In the IoT use case, the "user" is the device itself. IoT devices often communicate over TLS to their manufacturer about many things; there is no reason to make DNS special here.

Said another way, if you want to prevent IoT devices from using TLS for some information but not other information, maybe DNS is not the information you want to be always unprotected.

--Paul Hoffman

---

From: "John R Levine" <[email-masked]>
Date: 24 Dec 2019 23:10:58 -0500

> In the above case we may wonder whether the user, as opposed to the 
> device or app vendor, trusts the server and whether the server's 
> policies are consistent with those of the user.

In my experience if you asked 99% of app or device users this question, 
the answer would be huh? followed by, why doesn't my device or app work.

Asking users questions they don't understand is not good UI. 
Unfortunately it's where we too often end up in the IETF.

R's,
John

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Dec 2019 22:32:48 -0500

> Asking users questions they don't understand is not good
    > UI. Unfortunately it's where we too often end up in the IETF.

I agree: we can't really ask the user.

This is why I think that we need to get the DNS server policies into a
machine readable form.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 27 Dec 2019 10:27:08 +0100 (CET)

> Il 25/12/2019 05:10 John R Levine <[email-masked]> ha scritto:
> 

Part of the issue is also that there is a share of users - a minority, but not such a small one - which does understand those questions, and wants to keep full control on where their queries and their data are going. This is why we need to have both discussions: how to set good automated defaults for the average user, and how to allow smarter users to keep control.

--

---

From: Andrew Campling <[email-masked]>
Date: Sat, 28 Dec 2019 18:41:13 +0000

On Dec 23, 2019, at 16:52, Paul Hoffman <[email-masked]> wrote:

> In the IoT use case, the "user" is the device itself. IoT devices often communicate 
> over TLS to their manufacturer about many things; there is no reason to make DNS 
> special here.

I think one of the issues that I have is that I wouldn't accept that the device is the "user" in all instances - for example, I'd be confident that most purchasers of a Ring doorbell would classify themselves rather than either the bell or indeed Amazon as the "user" of the device.  More generally, I think that the presumption that a device can communicate with a manufacturer without the knowledge or consent of the user / owner of the device is problematic, and certainly is open to challenge from a privacy perspective in those jurisdictions where privacy is protected (eg under GDPR or its equivalents).  

Andrew

---

From: "John Levine" <[email-masked]>
Date: 28 Dec 2019 14:11:27 -0500

In article <[email-masked]> you write:
>I think one of the issues that I have is that I wouldn't accept that the device is the "user" in all instances - for
>example, I'd be confident that most purchasers of a Ring doorbell would classify themselves rather than either the bell or
>indeed Amazon as the "user" of the device.  More generally, I think that the presumption that a device can communicate
>with a manufacturer without the knowledge or consent of the user / owner of the device is problematic, and certainly is
>open to challenge from a privacy perspective in those jurisdictions where privacy is protected (eg under GDPR or its
>equivalents).  

I take your point, but that horse left the barn a decade ago.  Having
spent quite a while staring at the GDPR and arguing with people about
what it means, I am reasonably sure that the consumer IoT gadgets sold
in Europe are GDPR compliant because they need to talk to the
manufacturer to work.

There's a separate issue of whether the party at the other end follows
the GDPR rules, but I think that's way out of our scope.

In any event, I can promise you that if you design your network to
lock down DoH or the like, every smart camera will come with a flyer
with instructions how to turn off the firewall in popular routers so
the camera will work.

R's,
John

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 30 Dec 2019 10:15:00 +0100 (CET)

> Il 28/12/2019 20:11 John Levine <[email-masked]> ha scritto:
> 

...but only as far as the information they send to the manufacturer is strictly necessary for the purpose for which the user has bought the item, and has been disclosed through a proper consent request. And even if the processing of information is necessary to make the product work better, it will still be illegal if it is too intrusive and not properly disclosed to users - see for example the Google Assistant case ( https://techcrunch.com/2019/08/02/google-ordered-to-halt-human-review-of-voice-ai-recordings-over-privacy-risks/ ).

> with instructions how to turn off the firewall in popular routers so

Wouldn't it be a better world if the camera just had a way to ask to the local network how it should access the Internet, including which name service to use, and followed the instructions it receives? I'm not familiar with it, but I thought this was the purpose of MUD.

--

---

From: "John R Levine" <[email-masked]>
Date: 30 Dec 2019 10:08:16 -0500

> ...but only as far as the information they send to the manufacturer is strictly necessary for the purpose for which the user has bought the item, and has been disclosed through a proper consent req…

Sure, but none of that has anything to do with protocols.  It's all the 
semantics of what happens to the data.

> Wouldn't it be a better world if the camera just had a way to ask to the 
> local network how it should access the Internet, including which name 
> service to use, and followed the instructions it receives?

Ah, you mean some sort of dynamic host configuration protocol?  If only 
that were possible.

> I'm not familiar with it, but I thought this was the purpose of MUD.

No, MUD publishes a profile of the device's expected communication 
behavior, so the router can firewall it.  That makes it harder to attack 
the device, and harder for the device to cause trouble if it's 
compromised.  MUD is not about policy; it can say the device sends a 
real-time video feed of your baby back to China.

R's,
John