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

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

On 4 December 2015 at 01:47, Eitan Adler <lists@eitanadler.com> wrote:
> On 3 December 2015 at 09:16, Mike West <mkwst@google.com> wrote:
>> Hi Eitan!
>>
>> On Thu, Dec 3, 2015 at 1:49 AM, Eitan Adler <lists@eitanadler.com> wrote:
>>>
>>> I have some comments about the draft-west-cookie-prefixes-05 draft:
>>
>>
>> Great, thank you for taking a look!
>>
>>>
>>> The syntax is ugly, but extensible without having to introduce
>>> 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.
>
> Ideally we won't need any other prefixes.  That said, the RFC should
> be explicit about this.
>
>>> I'm concerned about the use of __ for both
>>> regular cookies and special handling cookies (such as __host and
>>> __secure).
>>
>>
>> What do you mean here? You're concerned that magic cookies like
>> (`__SECURE-whatever`) and boring cookies (like `__utma`) can both start with
>> "__"?
>
> Yes. See below.
>
>>> 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 "-"
>>
>>
>> I don't understand the concern. What dangers do you see in the current
>> 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
>

Received on Friday, 4 December 2015 04:26:14 UTC