Subject: draft-west-cookie-prefixes-05 comments

From: Eitan Adler <[email-masked]>
Date: Wed, 2 Dec 2015 19:49:43 -0500

On 12 November 2015 at 19:16, Mark Nottingham <[email-masked]> wrote:
> As discussed in Yokohama, we have several proposals for modifying RFC6265 ('Cookies'), including:
>
>  - https://tools.ietf.org/html/draft-west-leave-secure-cookies-alone
>  - https://tools.ietf.org/html/draft-west-cookie-prefixes
>  - https://tools.ietf.org/html/draft-west-first-party-cookies
>  - https://tools.ietf.org/html/draft-west-origin-cookies

Hi,

I have some comments about the draft-west-cookie-prefixes-05 draft:

The syntax is ugly, but extensible without having to introduce
additional extension points.  I'm concerned about the use of __ for both
regular cookies and special handling cookies (such as __host and __secure).

I'd like to see the prefix changed to one which it can be specified
that conformant implementations MUST NOT use a prefix other other than
those defined by an RFC.

Perhaps __-SECURE and __-HOST can be used? note the additional "-"

-- 
Eitan Adler

---

From: Mike West <[email-masked]>
Date: Thu, 3 Dec 2015 15:16:57 +0100

Hi Eitan!

> I have some comments about the draft-west-cookie-prefixes-05 draft:

Great, thank you for taking a look!

> additional extension points.

I'd be interested in hearing about the use cases for other prefixes, but
I'm hopeful that we won't need/want to add many prefixes. The two defined
in https://tools.ietf.org/html/draft-west-cookie-prefixes seem to close the
most pressing gaps.

> I'm concerned about the use of __ for both

What do you mean here? You're concerned that magic cookies like
(`__SECURE-whatever`) and boring cookies (like `__utma`) can both start
with "__"?

> Perhaps __-SECURE and __-HOST can be used? note the additional "-"

I don't understand the concern. What dangers do you see in the current
syntax? How does adding an additional `-` resolve them?

-mike

---

From: Eitan Adler <[email-masked]>
Date: Thu, 3 Dec 2015 09:47:53 -0500

On 3 December 2015 at 09:16, Mike West <[email-masked]> wrote:
> I'd be interested in hearing about the use cases for other prefixes, but I'm
> hopeful that we won't need/want to add many prefixes. The two defined in
> https://tools.ietf.org/html/draft-west-cookie-prefixes seem to close the
> most pressing gaps.

Ideally we won't need any other prefixes.  That said, the RFC should
be explicit about this.

> (`__SECURE-whatever`) and boring cookies (like `__utma`) can both start with
> "__"?

Yes. See below.

> syntax? How does adding an additional `-` resolve them?

When some prefixes can cause semantic changes and others are treated
as special it causes complexity in parsing, and in general
understanding of the system.  The proposal to add a "-" or any other
not-currently-used prefix is to make it clear that the prefix has
special meaning.

In other words its the difference between

 - All cookies that begin with "__-" are special
vs
- Some cookies that begin with __, __SECURE, and __HOST, have special
meaning, but most don't.

This isn't a purely technical argument -  no known implementations
will break - but an argument to reduce complexity.

Another concern is that in the unlikely event we will want another
prefix other than SECURE or HOST we won't need to scour the web to
ensure that the newly defined word isn't already used.

-- 
Eitan Adler

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Dec 2015 15:25:45 +1100

Is this a risk that can be mitigated by selecting another character,
say '*' or '~'?  I know that people like to use characters that are
valid identifiers in their language of choice, which biases toward '_'
and maybe sometimes '-'.  But there are other characters that can be
used in cookie names.

Just looking at the definition for token, I see: !#$%'*+.^|~ as all
being valid.  Obviously, RFC 2068 attached the semblance of a semantic
to '$', so that might be a bit of a mistake, as noted, but absent
information, I'd suggest that you could easily use ~~SECURE=foo and
grab the entire namespace after ~~ (or some other sequence of
characters that look like swearwords...)

---

From: Matthew Kerwin <[email-masked]>
Date: Fri, 4 Dec 2015 15:21:12 +1000

> characters that look like swearwords...)
​Hah, ~~SECURE ​ looks like it says "approximately secure." I like it.

If it's really an issue, I think it makes the most sense to choose
something that isn't valid in any language of choice, since there's a good
chance someone has used all the valid-looking ones somewhere in some hacky
kluge.

​Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Dec 2015 18:11:46 +1100

On 4 December 2015 at 16:21, Matthew Kerwin <[email-masked]> wrote:
> If it's really an issue, I think it makes the most sense to choose something
> that isn't valid in any language of choice, since there's a good chance
> someone has used all the valid-looking ones somewhere in some hacky kluge.

As long as APL exists, there will be a choice that uses any character
you can use :)

---

From: Mike West <[email-masked]>
Date: Fri, 4 Dec 2015 08:33:42 +0100

On Fri, Dec 4, 2015 at 5:25 AM, Martin Thomson <[email-masked]>
wrote:

> say '*' or '~'?

I'd first ask whether this is a risk worth mitigating. I'm not sure that it
is. :)

> to '$', so that might be a bit of a mistake, as noted

Right, we can't use "$" as a leading character; I've already gotten reports
from 3 developers who have tried and failed to get that working with their
cookie-parsing code (one at a Large Californian Internet Company). That's a
pretty high failure rate for a feature that isn't actually shipping yet. :)

> > Ideally we won't need any other prefixes.  That said, the RFC should

What would you like the RFC to say in this regard?

> > - Some cookies that begin with __, __SECURE, and __HOST, have special

Another way of phrasing this is "All cookies that begin with `__SECURE-`
and `__HOST-` are special." I'd suggest that this rule is fairly easily
understood.

> > ensure that the newly defined word isn't already used.

Honestly, I see this as a benefit. Adding prefixes should be hard, and we
shouldn't do it often. Asking whether it's worth it to scour the web for a
suitable prefix seems like a totally reasonable hurdle to place in front of
implementers.

Hurdles to the side, I also worry a bit about breaking applications that
use strangely named cookies. This is a miniscule risk, but Chrome's
telemetry system certainly has blind spots (most notably in The Enterprise,
where folks turn off any feature that looks like it might send remotely
interesting data to Google as a matter of course); I imagine Mozilla's
system is similarly hobbled. Given the known unknowns, I would prefer to
make the smallest change possible.

-mike

---

From: Eitan Adler <[email-masked]>
Date: Fri, 4 Dec 2015 15:54:23 -0800

> What would you like the RFC to say in this regard?

Something to extent of: cookie names that use the "special cookie"
prefix MUST NOT begin with any text other than those described by an
RFC.

> Another way of phrasing this is "All cookies that begin with `__SECURE-` and
> `__HOST-` are special." I'd suggest that this rule is fairly easily
> understood.
>

My concerns are ones of cleanliness and extensability.  If other
extensions are highly unlikely to occur, and the list of special
prefixes will be kept at exactly two, then my comments can be ignored.

-- 
Eitan Adler