Subject: Re: [http-state] Summary of discussion of Ticket 5 (Cookie ordering)

From: Adam Barth <[email-masked]>
Date: Sun, 11 Apr 2010 09:54:54 -0700

In the two months since I sent this email, there hasn't been a whole
lot more discussion on this topic.  We discussed the issue at the
working group meeting at IETF77.  Unfortunately, Daniel Stenberg
wasn't in attendance, so we missed out on his perspective.

A number of people (apologies for not recalling who) thought it was
important to specify the ordering.  Various folks had various ideas
about which ordering to use, although most agreed that the specific
ordering is less important than the need to specify an ordering.

My perspective is that we can debate endlessly which ordering to use
even though the particular ordering we choose doesn't matter nearly as
much as getting user agents to interoperate on some ordering.
Therefore, I'm going to leave the ordering requirement in the draft
and specify the ordering that Firefox (and some other browsers) use.
(Note that the draft admonishes server operators not to rely upon the
ordering.)

Adam

On Mon, Feb 15, 2010 at 4:47 PM, Adam Barth <[email-masked]> wrote:
> For reasons I don't entirely understand, the order cookies are
> presented in the Cookie header is somewhat controversial.  The
> discussion seems to have quieted down to some extent, so I thought now
> might be a good time to summarize what's been said thus far.
>
> == General Principles ==
>
> Daniel Stenberg suggests that we should specify only what needs to be
> specified and leave the rest to the implementors.  In particular, we
> should specify and document what needs to be done in order to work
> with the vast majority of sites, where he takes the "vast majority of
> sites" to be all (except three or more) of the top 500 sites.  He
> appears unwilling to specify a behavior if it's a very rare assumption
> that we can declare a server bug.  However, if sufficiently many
> servers assume that clients behave in a certain way, then we ought to
> specify that behavior.
>
> In the absence of evidence about what servers require, Adam Barth
> argues that we should specify the most specific behavior that is
> deployed by the most commonly used implementations.
>
> == Technical Details ==
>
> Daniel Stenberg agrees that the "most specific" version of two cookies
> with the same name should be sent first.  He agrees that the
> "sort-them-all" approach is the easiest to implement.  Based on this
> experience implementing libcurl, he doesn't think the creation-time of
> a cookie is relevant.
>
> Dan Winship supports specify the ordering, but mostly on general
> principles rather than specific implementation experience.
>
> Maciej Stachowiak would like a breakdown of which user agents employ
> which sorting algorithms.  He agues that not specifying the sort order
> isn't viable.
>
> Anne van Kesteren supports specify the ordering.
>
> Yngve Pettersen suggests that we continue to specify the ordering, at
> least for path.  Later, he recommends sorting on domain and path,
> ignoring creation-time (because creation-time is less predictable).
> He notes that Opera sorts based on domain first, path second, and
> creation-time third.
>
> Dan Witte confirms that Firefox sorts by path length and then by
> creation-time.  When Firefox dropped the creation-time sorting in
> 2004, at least one site broke, prompting Firefox to reinstate
> creation-time sorting.  He would be willing to change Firefox to match
> IE because he dislikes creation-time sorting (but implemented it
> because of compatibility issues).
>
> Paul E. Jones is skeptical that servers will be able to rely on user
> agent sorting behavior and would prefer that user agents never send
> two cookies with the same name.
>
> Achim Hoffmann notes that the cookie sequence is really important.  He
> is aware of some serious attacks (miss)using the order of cookies.  He
> recommends a specific sorting based on seven factors.
>
> == Specification Changes ==
>
> I've added this requirement to the server conformance section:
>
> [[
>          <t>Although cookies are serialized linearly in the Cookie header,
>          servers SHOULD NOT rely upon the serialization order. In particular,
>          if the Cookie header contains two cookies with the same name,
>          servers SHOULD NOT rely upon the order in which these cookies appear
>          in the header.</t>
> ]]
>
> == Action Items ==
>
> 1) Adam Barth will generate the compatibility matrix requested by
> Maciej Stachowiak.
>
> Adam
>

---

From: Daniel Stenberg <[email-masked]>
Date: Sun, 11 Apr 2010 20:10:55 +0200 (CEST)

On Sun, 11 Apr 2010, Adam Barth wrote:

> In the two months since I sent this email, there hasn't been a whole lot 
> more discussion on this topic.  We discussed the issue at the working group 
> meeting at IETF77.  Unfortunately, Daniel Stenberg wasn't in attendance, so 
> we missed out on his perspective.

Well, I've stated it on this list many times so I don't think my repeating it 
in person would've made a significant difference. I'm sad the outcome went 
this way, but I'm well aware of how these things work and I'll continue to 
argue my standpoint in other areas.

-- 

  / daniel.haxx.se

---

From: Work <[email-masked]>
Date: Sun, 11 Apr 2010 11:53:49 -0700

Sorry, I should have spoken up on this. I think that ideally the  
length of the domain attribute and the length of the path are the only  
functionally relevant ordering criteria.

In all cases, the most specific cookies ought to come first or web  
applications won't be able to explicitly set a cookie on a given  
domain and expect that siblings can't overturn said cookie.

However, it doesn't seem that specifying new behavior is really in the  
scope of this document, so I'm okay with a SHOULD classification of  
the current most common ad-hoc ordering and a MUST not for server  
dependance on any given ordering.

_Mark

On Apr 11, 2010, at 9:54 AM, Adam Barth <[email-masked]> wrote:

> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state

---

From: Work <[email-masked]>
Date: Sun, 11 Apr 2010 11:58:42 -0700

As an aside CFNetwork does return cookies of the most specific domain  
first, that much is clear from the code. I don't think that it's as  
clear that we send cookies with the longest paths first however.

_Mark

---

From: Adam Barth <[email-masked]>
Date: Thu, 15 Apr 2010 16:15:44 -0700

On Sun, Apr 11, 2010 at 11:53 AM, Work <[email-masked]> wrote:
> Sorry, I should have spoken up on this. I think that ideally the length of
> the domain attribute and the length of the path are the only functionally
> relevant ordering criteria.
>
> applications won't be able to explicitly set a cookie on a given domain and
> expect that siblings can't overturn said cookie.
>
> However, it doesn't seem that specifying new behavior is really in the scope
> of this document, so I'm okay with a SHOULD classification of the current
> most common ad-hoc ordering and a MUST not for server dependance on any
> given ordering.

We've generally shied away from MUST-level requirements for server
operators.  For example, we don't even have a MUST-level requirement
for not sending duplicate, conflicting attribute values.  We already
have a SHOULD-level requirement on servers, which hopefully explains
to folks who read the spec why order dependence is a bad idea.

As for the level of conformance requirement for the de facto / ad-hoc
ordering, a SHOULD-level requirement on the ordering might be a good
way to resolve this issue given the variety of opinion we've seen on
the list.  I'll write this up and add some more explanatory text to
help using agent implementors understand this requirement.

Thanks,
Adam

---

From: Adam Barth <[email-masked]>
Date: Thu, 15 Apr 2010 16:27:57 -0700

> help using agent implementors understand this requirement.

Ok, here's what I've got:

[[
          <t>The user agent SHOULD sort the cookie-list in the following
          order:
          <list style="symbols">
            <t>Cookies with longer paths are listed before cookies
            with shorter paths.</t>

            <t>Among cookies that have equal length path fields, cookies
            with earlier creation-times are listed before cookies with later
            creation-times.</t>
          </list>
          <list style="empty">
            <t>NOTE: Not all user agents sort the cookie-list in this order,
            but this order reflects common practice when this document was
            written. The specific ordering might not be optimal in every
            metric, but using the consensus ordering is a relatively low cost
            way to improve interoperability between user agents.</t>
          </list>
          </t>
]]

Adam

---

From: Achim Hoffmann <[email-masked]>
Date: Fri, 16 Apr 2010 12:11:20 +0200

>             way to improve interoperability between user agents.</t>

hmm, this description leads me to following example:

  * cookies send by www.some.tld in following chronological sequence

	Set-Cookie: key=val0;
	Set-Cookie: key=val1; path=/foo
	Set-Cookie: key=val2; path=/
	Set-Cookie: key=val3; path=/bar
	Set-Cookie: key=val4; domain=.some.tld
	Set-Cookie: key=val5; domain=.some.tld; path=/some/thing/very/long/to/ensure/being/first

  * cookies send by user agent for a request to http://www.some.tld/

	Cookie: key=val5; key=val1; key=val3; key=val2; key=val0; key=val4

I guess (but did not yet prove) that most browsers do not send cookies in this
(above) sequence. It would rather be:

	Cookie: key=val3; key=val1; key=val2; key=val0; key=val5; key=val4

So the new description does not show current practice.

According application security, I already explained that web applications which
rely on the ordering somehow, are prone to some attacks.
As there is no common behaviour according this ordering in current browsers, I'd
recommend that the spec does not recommend the cookie ordering. This is not wrong
and would force web application developers to implement proper measures:
	User agents MAY send cookies in any sequence.

KISS - keep it simple, stupid
Achim

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 16 Apr 2010 12:29:49 +0200 (CEST)

On Fri, 16 Apr 2010, Achim Hoffmann wrote:

> web applications which rely on the ordering somehow, are prone to some 
> attacks.

Sorry, but I must've missed that explanation. Where can we read up on the 
details of this claim?

> I'd recommend that the spec does not recommend the cookie ordering.

I strongly agree with this. It just seems that we're a minority and we can't 
get stuck on the sorting issue forever...

-- 

  / daniel.haxx.se

---

From: Dan Winship <[email-masked]>
Date: Fri, 16 Apr 2010 10:31:16 -0400

> rely on the ordering somehow, are prone to some attacks.

Right, everyone agrees with that.

> and would force web application developers to implement proper measures:

But there was already no recommended (total) ordering before, and yet
some web apps did depend on IE's ordering. And the sort of developers
who are going to write code that would depend on the exact ordering of
cookies are the sort of developers who aren't going to read the spec
anyway, so saying "don't assume an ordering" won't actually stop anyone.
(Though, yes, we should say it anyway.)

Now, if it's true that there isn't a consistent ordering among the major
browsers (which was something we didn't know at the start of the
debate), then maybe that will be enough to solve the problem; 5 years
ago people would test against just IE and call it good (and then blame
Firefox if the site didn't work with Firefox), but they can't really get
away with that any more.

-- Dan

---

From: Achim Hoffmann <[email-masked]>
Date: Fri, 16 Apr 2010 17:14:45 +0200

> But there was already no recommended (total) ordering before, and yet

Sorry, have to disagree here.
See my (still unanswered) posting
  http://www.webappsec.org/lists/websecurity/archive/2005-11/msg00097.html
and if we look at the posting in this thread, we see that the ordering is
not unique anyhow.

IIRC the purpose is to write down the status quo today.

> (Though, yes, we should say it anyway.)

:)
If the spec says "MAY have any order", they don't need to read the spec,
and security analysts can always blame the application developer without
refering the specs if something went wrong ;-)
As long as the protocol cannot ensure the correct usage (cookie odering here),
then the application developer is responsible for correct functionality of
h(is|er) application.

> debate), then maybe that will be enough to solve the problem;

hmm, my first suggestion was to define a strict ordering too. But it then
has to be

  "The user agent MUST ensure following ordering: ..."

anything else is a useless attempt to get it right, but opens a wide range
of interpretations, IMHO.

> .. 5 years

damn, my posting (see above) is just 4.5 years old :-/

> Firefox if the site didn't work with Firefox), but they can't really get

Hope this helps to make the security/quality impact better understandable
for such a simple thing like "cookie odering".
Achim

---

From: Achim Hoffmann <[email-masked]>
Date: Fri, 16 Apr 2010 17:33:18 +0200

> Sorry, have to disagree here.

oops, misread the sentence: have to agree for sure: there was no spec before.
So read my further patter is etry explanation please.

---

From: Adam Barth <[email-masked]>
Date: Fri, 16 Apr 2010 09:44:15 -0700

> get stuck on the sorting issue forever...

Indeed.  We're way off in the weeds on this issue.

> and if we look at the posting in this thread, we see that the ordering is

Here's how I would respond to your email:

] Does somebody know a paper/link where I can find a definition how browsers
] (should) send cookies?

http://tools.ietf.org/id/draft-ietf-httpstate-cookie

] For example Mozilla/FF seems to send the cookies in this order:

I don't believe you've done your reverse engineering correctly (or
maybe the behavior has changes since you wrote that email).

] Above examples are just a small set of tests, I guess that following
attributes
] are used somehow, somewhere also:

I don't believe that's correct.

] All these variations make tests complicated, that's why I'm asking if there
] exists a rule or alike.

Indeed.  That's why having everyone reverse engineer everyone else's
implementation is no good for interoperability, which is why we
started this working group.  :)

> IIRC the purpose is to write down the status quo today.

That's correct.  Does the current text of the draft not reflect the status quo?

> refering the specs if something went wrong ;-)

The spec already requires that servers not depend on the ordering.  If
you're interested in the blame game (which I'm not), the spec already
gives you grounds for blaming the application developer.

>        Set-Cookie: key=val5; domain=.some.tld; path=/some/thing/very/long/to/ensure/being/first

I've converted your test case to test ordering0001:

Set-Cookie: key=val0;
Set-Cookie: key=val1; path=/cookie-parser-result
Set-Cookie: key=val2; path=/
Set-Cookie: key=val3; path=/bar
Set-Cookie: key=val4; domain=.example.org
Set-Cookie: key=val5; domain=.example.org; path=/cookie-parser-result/foo
Location: /cookie-parser-result/foo/baz?ordering0001

I don't think it's possible for both val1 and val3 to appear in the
same Cookie header because neither is a prefix of the other.

>        Cookie: key=val5; key=val1; key=val3; key=val2; key=val0; key=val4

Here's the ordering that Internet Explorer, Firefox, and Chrome produce:

Cookie: key=val5; key=val1; key=val2; key=val4

Notice that the ordering matches the spec.  The cookie with val3 is
missing because /bar is not a prefix of the result URL (we have a
choice of either getting val1 or val3).  The cookie with val0 is
missing because the cookie is set from the path "/cookie-parser",
which gets a default path of "/" and so gets overwritten by val2.

> So the new description does not show current practice.

Perhaps you should run your test cases instead of making bold claims
like the above.

> rely on the ordering somehow, are prone to some attacks.

Which is why we require servers not to rely on the ordering.

>        User agents MAY send cookies in any sequence.

Do you have test cases that demonstrate that there is no common
ordering?  The test case that you presented above does not behave as
you claim.

> KISS - keep it simple, stupid

The cookie protocol is far from simple, but that's just how the world
is.  If I were designing a state management protocol today, I would
design something that was one or two orders of magnitude simpler.

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 16 Apr 2010 20:14:36 +0200 (CEST)

On Fri, 16 Apr 2010, Adam Barth wrote:

> The spec already requires that servers not depend on the ordering.

But only in a half-baked way. If we really wanted servers to not rely on the 
order we should not tell clients to sort them in any particular way. Since 
what is the point in sorting cookies when nobody is supposed to rely on the 
order?

-- 

  / daniel.haxx.se

---

From: Dan Winship <[email-masked]>
Date: Fri, 16 Apr 2010 14:30:35 -0400

On 04/16/2010 02:14 PM, Daniel Stenberg wrote:
> But only in a half-baked way. If we really wanted servers to not rely on
> the order we should not tell clients to sort them in any particular way.
> Since what is the point in sorting cookies when nobody is supposed to
> rely on the order?

The same as the point in parsing incorrectly formatted dates when nobody
is supposed to send anything but the correct format.

-- Dan

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 16 Apr 2010 20:38:00 +0200 (CEST)

On Fri, 16 Apr 2010, Dan Winship wrote:

>> Since what is the point in sorting cookies when nobody is supposed to rely 
>> on the order?
>
> The same as the point in parsing incorrectly formatted dates when nobody is 
> supposed to send anything but the correct format.

Perhaps. But it creates exactly *zero* incentive for server authors to 
actually change anything, and this habit will live on forever and I guess it 
will even grow once clients start acting more similar...

But okay. We've done this already. I'll try to hold myself on this subject.

-- 

  / daniel.haxx.se