Subject: [http-state] Ticket 6: host-only cookies

From: Adam Barth <[email-masked]>
Date: Fri, 22 Jan 2010 00:50:37 -0800

I raised this ticket because I wanted to check with the working group
since this is a non-trivial decision:
http://trac.tools.ietf.org/wg/httpstate/trac/ticket/6

== Overview ==

If http://example.com/ sends the following header:

Set-Cookie: foo=bar

what Cookie header should the user agent generate for http://qux.example.com/ ?

Firefox, Chrome, Safari, and Opera say that foo=bar is a "host-only"
cookie that is returned to example.com only.  Internet Explorer
doesn't have a concept of a host-only cookie and returns the cookie to
example.com and all of its subdomains, including qux.example.com.

The lack of host-only cookies in IE is a security issue because it
prevents hosts from keeping cookies confidential from their
subdomains.  This behavior surprises enough web developers to be on
Eric's cookie FAQ (see Q3):

http://blogs.msdn.com/ieinternals/archive/2009/08/20/WinINET-IE-Cookie-Internals-FAQ.aspx

== Proposal ==

1) Specify host-only cookies to match Firefox, Chrome, Safari, and
Opera.  This is best for security, and I think there's a good chance
that IE will adopt host-only cookies in future, but I don't have any
citable evidence for this belief.  (The draft currently matches this
proposal.)

== Alternatives ==

2) Specify the IE behavior.  I think this approach is a dead end
because I'd be very surprised if all the non-IE browsers weakened
their security in this regard.

3) Allow both behaviors.  This alternative is the worst for security
because it makes the cookie protocol less predictable.  When all the
other browsers agree on a behavior that's better than the IE behavior,
I think we can require the non-IE behavior.

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 22 Jan 2010 12:00:56 +0100 (CET)

On Fri, 22 Jan 2010, Adam Barth wrote:

> 1) Specify host-only cookies to match Firefox, Chrome, Safari, and Opera. 
> This is best for security, and I think there's a good chance that IE will 
> adopt host-only cookies in future, but I don't have any citable evidence for 
> this belief.  (The draft currently matches this proposal.)

Even though this would be the best security option (and in general I think it 
makes more sense), I don't think we can neglect that one rather widely used 
implementation doesn't do it this way.

Sites out there that depend on this bug/feature in IE will break. And we know 
there exist many IE-crafted sites out there (although I guess nobody really 
knows how many of those that might depend on this particular thing).

I'm guessing this is a difference that simply will remain for a good while 
forward. The non-IE browsers won't do it this way due to security and IE does 
it this way by tradition and the good old "we won't change any behaviors since 
then something will break for our users".

So, I'm afraid I'm leaning towards (3): Allow both behaviors.

-- 

  / daniel.haxx.se

---

From: Dan Winship <[email-masked]>
Date: Fri, 22 Jan 2010 09:37:40 -0500

> citable evidence for this belief.  (The draft currently matches this

The other argument in favor of this is that the host-only cookie rule
was part of the original Netscape spec, so this isn't just a case of
unspecified behavior where some browsers do one thing and others do
another, or of clients being-liberal-in-what-they-accept to work around
server problems. IE is just doing it wrong.

> I think we can require the non-IE behavior.

Well... allowing both behaviors doesn't *make* the protocol less
predictable, because the protocol already *is* less predictable, and
will continue to be for several years at least, regardless of what we
say. So we should document the unpredictability, so that server authors
will know that they have to take steps to protect themselves against
unintended cookie leakage in some cases.

So my vote is, require clients to implement host-only cookies (as the
Netscape spec did), but note in the corresponding server-side section
that some clients don't do this, with some discussion of the security
issues.

-- Dan

---

From: Adam Barth <[email-masked]>
Date: Fri, 22 Jan 2010 09:36:29 -0800

> that some clients don't do this, with some discussion of the security

We're also going to write an informative deviation description
document that catalogs all the places we know of where user agents
diverge from the specification.  Do you think that would be a more
appropriate place to warn servers about IE's behavior?

Adam

---

From: Adam Barth <[email-masked]>
Date: Fri, 22 Jan 2010 09:49:11 -0800

On Fri, Jan 22, 2010 at 3:00 AM, Daniel Stenberg <[email-masked]> wrote:
> Even though this would be the best security option (and in general I think
> it makes more sense), I don't think we can neglect that one rather widely
> used implementation doesn't do it this way.

We certainly can't neglect that the most widely used implementation
has a different behavior, hence the discussion.

> Sites out there that depend on this bug/feature in IE will break. And we
> know there exist many IE-crafted sites out there (although I guess nobody
> really knows how many of those that might depend on this particular thing).

There are a great many places where Internet Explorer diverges from
Internet and web standards.  When implementing an HTML user agent, for
example, one has to think carefully about whether to implement some
features the IE way or the standard way.  Often these decisions are
not easy and require substantial implementation experience.

In this case, we see that every non-IE user agent has decided to
support host-only cookies.  Given the collective market share of these
user agents, that's strong evidence that the behavior is sufficiently
interoperable with existing servers.  Also, there is a large security
benefit to implementing host-only cookies.  For these reasons, the
benefit of host-only cookies outweigh the potential compatibility
costs.

> forward. The non-IE browsers won't do it this way due to security and IE
> does it this way by tradition and the good old "we won't change any
> behaviors since then something will break for our users".
>

I believe that if we take approach (1) that, in the future, IE will
join all the other user agents in supporting host-only cookies.

I understand that it can be challenging to determine when to specify
existing behavior and when it's appropriate write a requirement that
makes IE non-conformant.  In this case, the fact that every other user
agent has the same more secure behavior is strong evidence that we
ought to require that behavior.  At some level, this is a judgment
call that reasonable people can disagree with.

Adam

---

From: Dan Winship <[email-masked]>
Date: Fri, 22 Jan 2010 14:09:57 -0500

On 01/22/2010 12:49 PM, Adam Barth wrote:
> interoperable with existing servers.

In this case the problem isn't whether the client behavior is
interoperable with servers, it's whether the server behavior (of
expecting host-only cookies to actually be treated as host-only) is
interoperable with clients. And more than 50% of the time, it's not.

> Also, there is a large security
> benefit to implementing host-only cookies.

But there's a large security FAIL for servers if their security model
assumes that clients will implement host-only cookies, and then it turns
out that some clients don't. And since we already know that some
(/many/most) clients don't, sites that want to be secure have to find
some other way to protect themselves and their users that doesn't depend
on having working host-only cookies. (Because, as recently demonstrated,
hackers can do plenty of damage even if they can only hack IE users. :)

-- Dan

---

From: Adam Barth <[email-masked]>
Date: Fri, 22 Jan 2010 11:16:05 -0800

> hackers can do plenty of damage even if they can only hack IE users. :)

Indeed.  I think you're arguing that we should warn servers about IE's
behavior in the specification directly instead of referring to a
second document.  I'd be inclined to note this behavior where we
explain host-only cookies and again in the security consideration
section.  Those should be the two most common places folks will look
for this kind of information.

Adam

---

From: Maciej Stachowiak <[email-masked]>
Date: Sat, 23 Jan 2010 20:36:39 -0800

On Jan 22, 2010, at 3:00 AM, Daniel Stenberg wrote:

>> 1) Specify host-only cookies to match Firefox, Chrome, Safari, and Opera. This is best for security, and I think there's a good chance that IE will adopt host-only cookies in future, but I don't have any citable evidence for this belief.  (The draft currently matches this proposal.)
> 
> Even though this would be the best security option (and in general I think it makes more sense), I don't think we can neglect that one rather widely used implementation doesn't do it this way.
> 
> Sites out there that depend on this bug/feature in IE will break. And we know there exist many IE-crafted sites out there (although I guess nobody really knows how many of those that might depend on this particular thing).
> 
> I'm guessing this is a difference that simply will remain for a good while forward. The non-IE browsers won't do it this way due to security and IE does it this way by tradition and the good old "we won't change any behaviors since then something will break for our users".
> 

If Microsoft is unwilling to change their behavior, then I'd like to hear it from them rather than guessing. Are there any Microsoft reps in this group? Can we get any to join?

I would strongly prefer a single behavior unless we get a clear statement from Microsoft that they absolutely will not change.

Regards,
Maciej

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 28 Jan 2010 13:47:37 -0800

> I would strongly prefer a single behavior unless we get a clear statement from Microsoft that they absolutely will not change.

On security issues, there is no Microsoft exception.  The spec will
define the more secure alternative and the vendors will adjust their
behavior long before we are done.  Servers are fully-capable of adjusting
their behavior for previously deployed user agents' bugs without further
assistance from the standard.

....Roy

---

From: Adam Barth <[email-masked]>
Date: Thu, 28 Jan 2010 13:53:24 -0800

> assistance from the standard.

I agree with your conclusion but I disagree with your tone.  I'm not
sure yours is the final word on what the spec will or will not define.
 Your tone is arrogant and disrespectful.

Adam

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 28 Jan 2010 14:12:45 -0800

> Your tone is arrogant and disrespectful.

This is an IETF spec, so it will obey IETF norms, and I can tell you
that it won't pass IESG review with a non-secure alternative being
allowed as part of the proposed standard.  My tone is from experience
in writing standards and experience in writing servers.

This is the last comment I will respond to you regarding tone.
You are not my mother and you are not my chair.  You will either
stop playing these junior psychology games learned from HTML5
or I will ask the chairs to remove you as draft editor.

....Roy

---

From: Adam Barth <[email-masked]>
Date: Thu, 28 Jan 2010 23:17:08 -0800

Roy,

I'm sorry for making the discussion personal instead of technical.
I'll keep to the technical merits in the future.  If you see me
stepping over the line again, please don't hesitate to call me on it.

Thanks,
Adam

---

From: Bil Corry <[email-masked]>
Date: Thu, 28 Jan 2010 23:24:04 -0800

> assistance from the standard.

and:

> in writing standards and experience in writing servers.

The spec we produce may not pass IESG review anyway given we're specifying behavior that violates RFC 2109 (and presumably httpbis).  The purpose of this WG is to create a spec that reflects how cookies are actually implemented in real life across common UAs and servers, including the insecure and inconsistent behavior.  Your position that 'vendors will adjust their behavior' has not borne out as RFC 2965 illustrates (and the very reason for this WG).

We will produce a 'real-life' cookie spec.  It will be useful to implementors seeking to make their products as broadly compatible as possible and is long overdue.  It's up to the IETF if they want to accept it, but that doesn't change our purpose and charter, nor does it reduce the need for our document and the value it will bring to the internet community at large.

Going back to the issue at hand, if Microsoft is unwilling to adopt the more secure behavior, then our charter states we must "seek consensus to reduce variation by selecting among the most widely used variations."  Note that it doesn't say we must eliminate variation, only reduce it.  And it's consensus-based.  Your vote for option 1 has been noted.

- Bil

---

From: Adam Barth <[email-masked]>
Date: Thu, 28 Jan 2010 23:28:57 -0800

On Thu, Jan 28, 2010 at 11:24 PM, Bil Corry <[email-masked]> wrote:
> Going back to the issue at hand, if Microsoft is unwilling to adopt the more secure behavior,

For what it's worth, we haven't heard anyone from Microsoft refuse to
implement host-only cookies.  Of course, an explicit message of
support for host-only cookies from Redmond would be ideal, but the
indications I've seen have been generally positive.

Adam

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 29 Jan 2010 00:47:17 -0700

<Chair>

It is far too easy to lose sight of the issues and get bogged down in personal commentary. We've got plenty of technical challenges to sort through and I'd like to keep this effort on topic.

Roy's comments correctly reflect IETF process and guidelines. However, there are no absolutes and the guiding principal is always reaching rough consensus. That means we don't count votes and need to address each and every concern or objection raised. It is also common for an IETF proposed standard to document existing practice even when it is insecure or non-compliant, as long as it is explicitly called out and noted clearly.

Jeff and I are here to help with the process and to make sure we successfully fulfill our charter in a manner that is consistent with IETF process.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Bil Corry
> Sent: Thursday, January 28, 2010 11:24 PM
> To: Roy T. Fielding
> Cc: Daniel Stenberg; http-state
> Subject: Re: [http-state] Ticket 6: host-only cookies
> 
> >>>> that IE will adopt host-only cookies in future, but I don't have
> >>>> any citable evidence for this belief.  (The draft currently matches
> >>>> this proposal.)
> >>> Even though this would be the best security option (and in general I
> think it makes more sense), I don't think we can neglect that one rather
> widely used implementation doesn't do it this way.
> >>>
> it this way by tradition and the good old "we won't change any behaviors
> since then something will break for our users".
> >>>
> >> If Microsoft is unwilling to change their behavior, then I'd like to hear it
> from them rather than guessing. Are there any Microsoft reps in this group?
> Can we get any to join?
> >>
> >> I would strongly prefer a single behavior unless we get a clear statement
> from Microsoft that they absolutely will not change.
> >
> > behavior long before we are done.  Servers are fully-capable of
> > adjusting their behavior for previously deployed user agents' bugs
> > without further assistance from the standard.
> 
> and:
> 
> The spec we produce may not pass IESG review anyway given we're
> specifying behavior that violates RFC 2109 (and presumably httpbis).  The
> purpose of this WG is to create a spec that reflects how cookies are actually
> implemented in real life across common UAs and servers, including the
> insecure and inconsistent behavior.  Your position that 'vendors will adjust
> their behavior' has not borne out as RFC 2965 illustrates (and the very reason
> for this WG).
> 
> We will produce a 'real-life' cookie spec.  It will be useful to implementors
> seeking to make their products as broadly compatible as possible and is long
> overdue.  It's up to the IETF if they want to accept it, but that doesn't change
> our purpose and charter, nor does it reduce the need for our document and
> the value it will bring to the internet community at large.
> 
> Going back to the issue at hand, if Microsoft is unwilling to adopt the more
> secure behavior, then our charter states we must "seek consensus to reduce
> variation by selecting among the most widely used variations."  Note that it
> doesn't say we must eliminate variation, only reduce it.  And it's consensus-
> based.  Your vote for option 1 has been noted.
> 
> 
> - Bil
> 
> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state

---

From: Julian Reschke <[email-masked]>
Date: Fri, 29 Jan 2010 09:21:38 +0100

Bil Corry wrote:
> ...
> ...

Where specifically do you expect a violation of HTTPbis, except for the 
well-known issue about the header syntax not following the HTTP rules 
for repeated headers?

BR, Julian

---

From: Bil Corry <[email-masked]>
Date: Fri, 29 Jan 2010 00:34:23 -0800

Julian Reschke wrote on 1/29/2010 12:21 AM: 
>> specifying behavior that violates RFC 2109 (and presumably httpbis). 
>> The purpose of this WG is to create a spec that reflects how cookies
>> are actually implemented in real life across common UAs and servers,
>> including the insecure and inconsistent behavior.  Your position that
>> 'vendors will adjust their behavior' has not borne out as RFC 2965
>> illustrates (and the very reason for this WG).
>> ...
> 

That's what I was thinking of.  It's a MUST-level rule.

- Bil

---

From: Adam Barth <[email-masked]>
Date: Fri, 29 Jan 2010 00:38:09 -0800

> That's what I was thinking of.  It's a MUST-level rule.

There's also a minor point about parsing the Date header:

[[
Let server-date be the date obtained by parsing the contents of
the last Date header field as a cookie-date.
]]

http://tools.ietf.org/html/draft-ietf-httpstate-cookie-02#section-5.2.2

I'm not sure whether that's a big deal though.

Adam

---

From: Julian Reschke <[email-masked]>
Date: Fri, 29 Jan 2010 09:49:43 +0100

> That's what I was thinking of.  It's a MUST-level rule.

Just checking :-)

For now HTTPbis states that Set-Cookie violates that requirement 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-08.html#rfc.section.3.2.p.6>).

We haven't really decided yet what to do with the normative requirement 
(allow this as a single exception?).

Best regards, Julian

---

From: Dan Winship <[email-masked]>
Date: Fri, 29 Jan 2010 09:23:25 -0500

> I'm not sure whether that's a big deal though.

2616 and httpbis both say:

      Note: Recipients of date values are encouraged to be robust in
      accepting date values that may have been sent by non-HTTP
      applications

So, you're ok.

Though I'm not convinced the text is needed; the Date header is most
likely generated by a lower-level part of the server stack that was
written by people who are actually aware of the relevant specs. When I
was logging my cookie traffic a few years ago, despite all the
variations I found in cookie Expires attributes, I only found a single
non-rfc1123 Date header, and that was from a guy who had written his own
http server. (And he'd actually already noticed that bug and fixed it,
but not yet deployed the fixed version yet.)

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 29 Jan 2010 12:09:56 -0800

On Thu, Jan 28, 2010 at 2:12 PM, Roy T. Fielding <[email-masked]> wrote:

> allowed as part of the proposed standard.

IESG review has gotten more flexible in some ways in the four years
I've been on the IESG.  I would certainly expect a document to pass
IESG review (and if I saw any counter-arguments, would expect
excellent and well-informed arguments against the document) if
 - it clearly stated it was documenting existing behavior and
explained in descriptive terms how to interoperate with it
 - it stated that supporting the non-secure alternative in browsers
was NOT RECOMMENDED for best user experience
 - it stated that relying on the non-secure alternative in sites was
deprecated and NOT RECOMMENDED

I'm not saying that's the best approach for this particular issue, but
I'd rather debate what is the best approach for this particular issue
first, before worrying about what some future review group might or
might not do.

Lisa