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

From: Blake Frantz <[email-masked]>
Date: Mon, 1 Feb 2010 10:32:42 -0600

I support Dan's approach.

B
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Winship
Sent: Friday, January 22, 2010 6:38 AM
To: Adam Barth
Cc: http-state
Subject: Re: [http-state] Ticket 6: host-only cookies

On 01/22/2010 03:50 AM, 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.)

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.

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

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
_______________________________________________
http-state mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/http-state

---

From: Adam Barth <[email-masked]>
Date: Mon, 1 Feb 2010 23:00:07 -0800

I've added the following text to the server section, as recommend by
Dan Winship:

              <t>WARNING: Some legacy user agents treat an absent Domain
              attribute as if the Domain attribute were present and contained
              the current host name. For example, if example.com returns a
              Set-Cookie header without a Domain attribute, these user agents
              will send the cookie to www.example.com.</t>

Adam

---

From: Bil Corry <[email-masked]>
Date: Tue, 02 Feb 2010 06:47:00 -0800

>               will send the cookie to www.example.com.</t>

Is it "example.com" that assumes "www.example.com"?  Or "www.example.com" assumes "www.example.com"?  Or both?

- Bil

---

From: Adam Barth <[email-masked]>
Date: Tue, 2 Feb 2010 07:37:53 -0800

> Is it "example.com" that assumes "www.example.com"?  Or "www.example.com" assumes "www.example.com"?  Or both?

I'm not sure I understand your question.  Can you phrase it more
operationally (in terms of who sends which messages to whom)?

Adam

---

From: Dave Kristol <[email-masked]>
Date: Tue, 02 Feb 2010 11:37:28 -0500

>               will send the cookie to www.example.com.</t>

If the implied Domain attribute is example.com, then the user agent may 
only return the cookie to example.com.

Dave Kristol

---

From: Adam Barth <[email-masked]>
Date: Tue, 2 Feb 2010 09:13:06 -0800

On Tue, Feb 2, 2010 at 8:37 AM, Dave Kristol <[email-masked]> wrote:
> If the implied Domain attribute is example.com, then the user agent may only
> return the cookie to example.com.

Do you mean that

Set-Cookie: foo=bar; Domain=example.com

and

Set-Cookie: foo=bar; Domain=.example.com

are treated differently by user agents?  That might be true according
to 2109 (I'd have to check), but I don't think that's how user agents
work in practice.  They appear to ignore the leading dot.  If you have
a test case that show a difference, I'd be very interested in seeing
it.

Adam

---

From: Dave Kristol <[email-masked]>
Date: Tue, 02 Feb 2010 14:14:17 -0500

> a test case that show a difference, I'd be very interested in seeing

That is what I meant, and I do not have a test case.  That is what 2109 
said, and I believe (though it's been many years now... ugh!) I adopted 
that from Netscape's spec.  Generally speaking, the idea was that, in 
the absence of Domain=, the cookie should be returned only to the server 
that sent it.

Dave Kristol

---

From: Adam Barth <[email-masked]>
Date: Tue, 2 Feb 2010 11:35:30 -0800

On Tue, Feb 2, 2010 at 11:14 AM, Dave Kristol
<[email-masked]> wrote:
> said, and I believe (though it's been many years now... ugh!) I adopted that
> from Netscape's spec.  Generally speaking, the idea was that, in the absence
> of Domain=, the cookie should be returned only to the server that sent it.

I believe this is the line of code in Firefox that causes the leading
dot in the domain attribute to be ignored.

http://mxr.mozilla.org/mozilla-central/source/netwerk/cookie/src/nsCookieService.cpp#2159

There's a similar line of code in Chrome in the GetCookieDomainKey
function in this file:

http://src.chromium.org/viewvc/chrome/trunk/src/net/base/cookie_monster.cc?view=markup

Here's the comment:

  // Get the normalized domain specified in cookie line.
  // Note: The RFC says we can reject a cookie if the domain
  // attribute does not start with a dot. IE/FF/Safari however, allow a cookie
  // of the form domain=my.domain.com, treating it the same as
  // domain=.my.domain.com -- for compatibility we do the same here.  Firefox
  // also treats domain=.....my.domain.com like domain=.my.domain.com, but
  // neither IE nor Safari do this, and we don't either.

Note that Firefox now acts like IE/Chrome/Safari in regards to
Domain=.....my.domain.com

Adam

---

From: Bil Corry <[email-masked]>
Date: Wed, 03 Feb 2010 10:47:33 -0800

> operationally (in terms of who sends which messages to whom)?

Nevermind, not sure what I was thinking.  Obviously not enough sleep yesterday.

- Bil

---

From: Mark Pauley <[email-masked]>
Date: Wed, 3 Feb 2010 11:40:26 -0800

CFNetwork used to treat domain attributes starting without a dot literally, but I think we've gone back to prepending the dot due to compatibility issues.