Subject: Cookie-Attribute request header proposal

From: David Eckel <[email-masked]>
Date: Thu, 01 Sep 2016 22:09:14 +0000

In https://github.com/httpwg/http-extensions/issues/223 the idea of a Cookie-Attribute request header was suggested as a way to inform HTTP servers if a cookie could be trusted or not, without breaking backwards compatibility.  It would work as follows in the hypothetical request to https://example.com/:

   GET / HTTP/1.1
   Host: example.com
   Cookie: tz=America/Los_Angeles;SESSIONID=a1b2c3
   Cookie-Attribute: ;Secure,HttpOnly,SameSite=Strict

The order of the attributes would match the order of the cookies. In the above example, the server could be confident that the SESSIONID cookie was set over a secure connection and was not vulnerable to being set via an XSS attack. It can also infer that the tz cookie may have been set by an untrusted party, and might choose to ignore it.

To accommodate more security and non-security related use cases, the Cookie-Attribute header could also include all of the other attributes, like Domain, Path, Expires.  Due to header size concerns they probably shouldn't be included by default.  Servers could opt-in to receiving these additional attributes by setting a uniquely named cookie that enumerates desired attributes, like "__Cookie-Attribute=Path,Domain". This could be useful when debugging, deleting cookies, and distinguishing between multiple cookies with the same name.  Example:

   GET /index HTTP/1.1
   Host: www.example.com
   Cookie: analyticsId=1;analyticsId=2;__Cookie-Attribute=Path,Domain
   Cookie-Attribute: Path=/,Domain=www.example.com;Path=/index,Domain=.example.com;Path=/,Domain=www.example.com

Known concerns:
   - Sending a new header and attributes increases the request size (per mnot's suggestion, this could be partially mitigated by abbreviating the header to something like "Cookie-A: ;S,H,SS=S" in the first example)
   - Opt-in security means a long road to adoption
   - Overlaps with Secure flag improvements in https://github.com/httpwg/http-extensions/blob/master/draft-ietf-httpbis-cookie-alone.md

Thoughts?

David Eckel

---

From: Daniel Stenberg <[email-masked]>
Date: Sun, 4 Sep 2016 13:05:53 +0200 (CEST)

On Thu, 1 Sep 2016, David Eckel wrote:

> Cookie-Attribute: 
> Path=/,Domain=www.example.com;Path=/index,Domain=.example.com;Path=/,Domain=www.example.com

> - Opt-in security means a long road to adoption

It's too long road IMO. It'll make every server implementation having to 
default to non-supporting clients and there will never be 100% compliance so 
this header will significantly complicate the server (and client) 
implementations for a very long time (complete deprecating things on the 
Internet is hard and all that) and yet for any client that wants to avoid that 
setup they'll just not send the header...

This, in an area that has turned out harder to change than most other HTTP 
areas (remember all the funky cookies RFCs that have been attemped through the 
years) since (I suspect) server side cookie implementations are so often 
custom and hand rolled out and are not just half a dozen major implmentations 
you can upgrade to the latest version and be done with it.

So no, I don't see this suggestion as a good road forward.

-- 

  / daniel.haxx.se