Subject: [http-state] Welcome to http-state

From: Bil Corry <[email-masked]>
Date: Fri, 09 Jan 2009 12:08:25 -0600

It appears the subscriptions have subsided, so thank you to everyone who has joined so far.

== First, some background history == 

Some time ago on OWASP's Intrinsic Security list, I brought up the issue of HTTPOnly not being consistently implemented (or lacking implementation altogether) across the major browsers, based mostly on OWASP's HTTPOnly resource page:

	http://www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HTTPOnly

Jim Manico responded that he was actively promoting HTTPOnly implementation to various browsers and welcomed help to do more.  In that conversation, we agreed that a uniform specification would probably be beneficial for the browser vendors and we started a group to do so.  In promoting the group across various lists, I consistently received feedback that *cookies* needed a specification, and why were we bothering with HTTPOnly.  This group at IETF is the result of our decision to take on the entire cookie spec, not just HTTPOnly.

== Goal for this group ==

Ultimately, the purpose of this group is to create an updated HTTP State Management Mechanism RFC (aka cookies) that will supersede the Netscape spec, RFCs 2109, 2964, 2965 then add in real-world usage (e.g. HTTPOnly), and possibly add in additional features and possibly merge in draft-broyer-http-cookie-auth-00.txt and draft-pettersen-cookie-v2-03.txt.

I'm assuming an update to bcp44 is probably needed as well, but truthfully I haven't looked at it.

Did I miss anything relevant to creating an update cookie RFC?

== Creating a Working Group ==

In order to create a RFC, we need a Working Group.  In order to create a Working Group, we need enough interested people to join a BOF at an IETF meeting and to volunteer to help run the Working Group:

	http://www.ietf.org/tao.html#rfc.section.6

I'll be attending the next IETF meeting and don't mind taking on the role of Working Group Chair, but I will need others to also attend, lend support and volunteer for the various responsibilities required.

The next IETF meeting is March 22-27, 2009 in San Francisco:

	http://www.ietf.org/meetings/74/

If you will be attending, please let me know.  I'll approach Lisa Dusseault about having a BOF at the next IETF meeting and would like to give her an idea of how many people are already interested in it.

== Initial first steps ==

While we work on forming a Working Group, we can start the actual RFC process now by working on creating an Internet Draft:

	http://www.ietf.org/tao.html#rfc.section.8.1

There are a few ways to get started; I'm thinking that taking an inventory of what is wrong or missing from RFC2109 as compared to the "real world" may be a good place to start.

Thoughts?

- Bil

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

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 9 Jan 2009 20:02:48 +0100 (CET)

> 	http://www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HTTPOnly

While not being a browser, libcurl is a HTTP library that supports cookies and 
even HTTPOnly ones and it is used in browsers (and browser-like applications) 
at times.

> There are a few ways to get started; I'm thinking that taking an inventory 
> of what is wrong or missing from RFC2109 as compared to the "real world" may 
> be a good place to start.

It sounds like a fair way to get started, but RFC2109 is quite far away from 
how cookies work in real life so the differences are going to be substantial.

-- 

  / daniel.haxx.se

---

From: "Blake Frantz" <[email-masked]>
Date: Mon, 12 Jan 2009 14:51:54 -0500

A couple other quick items that may be worth chewing over:

1. While RFC2109 and draft-pettersen-cookie-v2-03.txt define the
'Secure' cookie-av to advise the user-agent against sending the cookie
over an insecure transport they do not define the desired user-agent
behavior for cross scheme writing. For example, http://foo.bar
clobbering a cookie set by https://foo.bar. 

2. RFC2109 and draft-pettersen-cookie-v2-03.txt define rules for
path-matching but fail to clearly indicate if these are case sensitive
comparisons. Removing some ambiguity in this area may be beneficial. 

Let me know if I have overlooked something that defines the above - it's
more than possible :)

Blake

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bil Corry
Sent: Friday, January 09, 2009 10:08 AM
To: [email-masked]
Subject: [http-state] Welcome to http-state

It appears the subscriptions have subsided, so thank you to everyone who
has joined so far.

Some time ago on OWASP's Intrinsic Security list, I brought up the issue
of HTTPOnly not being consistently implemented (or lacking
implementation altogether) across the major browsers, based mostly on
OWASP's HTTPOnly resource page:

Jim Manico responded that he was actively promoting HTTPOnly
implementation to various browsers and welcomed help to do more.  In
that conversation, we agreed that a uniform specification would probably
be beneficial for the browser vendors and we started a group to do so.
In promoting the group across various lists, I consistently received
feedback that *cookies* needed a specification, and why were we
bothering with HTTPOnly.  This group at IETF is the result of our
decision to take on the entire cookie spec, not just HTTPOnly.

Ultimately, the purpose of this group is to create an updated HTTP State
Management Mechanism RFC (aka cookies) that will supersede the Netscape
spec, RFCs 2109, 2964, 2965 then add in real-world usage (e.g.
HTTPOnly), and possibly add in additional features and possibly merge in
draft-broyer-http-cookie-auth-00.txt and
draft-pettersen-cookie-v2-03.txt.

I'm assuming an update to bcp44 is probably needed as well, but
truthfully I haven't looked at it.

In order to create a RFC, we need a Working Group.  In order to create a
Working Group, we need enough interested people to join a BOF at an IETF
meeting and to volunteer to help run the Working Group:

I'll be attending the next IETF meeting and don't mind taking on the
role of Working Group Chair, but I will need others to also attend, lend
support and volunteer for the various responsibilities required.

If you will be attending, please let me know.  I'll approach Lisa
Dusseault about having a BOF at the next IETF meeting and would like to
give her an idea of how many people are already interested in it.

While we work on forming a Working Group, we can start the actual RFC
process now by working on creating an Internet Draft:

There are a few ways to get started; I'm thinking that taking an
inventory of what is wrong or missing from RFC2109 as compared to the
"real world" may be a good place to start.

Thoughts?

- Bil

---

From: "Adam Barth" <[email-masked]>
Date: Mon, 12 Jan 2009 11:59:30 -0800

> clobbering a cookie set by https://foo.bar.

Historically, cross-scheme clobbering has been allowed by user agents
because it is impossible to prevent with a bounded amount of storage
(due to eviction of Secure cookies).

Adam

---

From: "Blake Frantz" <[email-masked]>
Date: Mon, 12 Jan 2009 16:47:22 -0500

Agreed that cross-scheme clobbering is historically allowed by user
agents. However, clobbering a cookie is different than causing a cookie
to be evicted. The former impacts the integrity of the cookie while the
latter impacts cookie availability. The purpose of an anti-clobber
mechanism is to protect the integrity of the Secure cookie. To be
effective, the user agent must treat cookies of the same origin
(domain-match + path-match) and NAME distinctly if their schemes differ.
This implies adding a scheme-match check to the user agent. I see such a
mechanism as a defense in depth measure - akin to HttpOnly. I'm
interested in hearing what everyone thinks about the utility of such a
control. 

Blake

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Adam Barth
Sent: Monday, January 12, 2009 12:00 PM
To: Discuss HTTP State Management Mechanism
Subject: Re: [http-state] Welcome to http-state

Adam

---

From: "Adam Barth" <[email-masked]>
Date: Mon, 12 Jan 2009 13:59:43 -0800

On Mon, Jan 12, 2009 at 1:47 PM, Blake Frantz <[email-masked]> wrote:
> mechanism is to protect the integrity of the Secure cookie.

The attacker can still disrupt the integrity of the Secure cookie by
first causing the cookie to be evicted and then creating a new,
non-Secure cookie with the same name.  This has the same effect as
overwriting the Secure cookie.

An alternate way to protect the integrity of Secure cookies is to add
a "Cookie-Integrity" header that lists the cookies set over HTTPS, as
described in 6.2 of
http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf

> I see such a mechanism as a defense in depth measure - akin to HttpOnly.

The Cookie-Integrity header has two advantages over altering the
semantics of Set-Cookie:

1) It is backwards compatible with existing servers who might
legitimately overwrite Secure cookies over HTTPS (for example, during
"logout").

2) It protects the integrity of the cookies in a clearly defined threat model.

Adam

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Mon, 12 Jan 2009 23:41:31 +0100

> http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf

Please note that RFC2965 already have such integrity checking through the  
$Domain, $Path and $Port attributes.

It might be that $Secure should be added as well, but using Port="443"  
should already take care of that rather nicely.

Also, my cookie-v2 draft suggest always sending the $Domain&Co parameters  
to allow servers to verify the domain of a cookie, and a $Origin attribute  
for v0 and v1 cookies to permit the receiver to know who set the cookie.

-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************
_______________________________________________
http-state mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/http-state

---

From: Bil Corry <[email-masked]>
Date: Mon, 12 Jan 2009 16:48:04 -0600

> The Cookie-Integrity header has two advantages over altering the

I brought this up on the old list; what about using $Version instead?

Something like:

	Set-Cookie: a=b; Version="3"; HTTPOnly; Secure

which the browser responds:

	Cookie: $Version="3"; a=b; $Integrity="HTTPOnly,Secure"

Of course, we're reworking the cookie spec, so presumably we can choose a better method (which may be the Cookie-Integrity header).  One idea I tossed around with Yngve was to repurpose Cookie2 (which only Opera currently supports) and make it the "new" cookie standard.  Then it's just a matter of educating developers to use Cookie2 instead of Cookie (and makes discussion about the update easier).  Because of the limited deployment of Cookie2, I'd imagine any backwards compatibility problems would be also limited.

- Bil

---

From: "Adam Barth" <[email-masked]>
Date: Mon, 12 Jan 2009 14:48:30 -0800

On Mon, Jan 12, 2009 at 2:41 PM, Yngve N. Pettersen (Developer Opera
> $Domain, $Path and $Port attributes.

Cool!

> should already take care of that rather nicely.

Why is that?  It seems like an active network attack (which is the
kind of attacker we're trying to stop) can just fake an HTTP server on
port 443 and spoof that attribute.

> Also, my cookie-v2 draft suggest always sending the $Domain&Co parameters to
> allow servers to verify the domain of a cookie, and a $Origin attribute for
> v0 and v1 cookies to permit the receiver to know who set the cookie.

If you can tolerate the bandwidth, sending the ASCII serialization of
the origin (including the scheme) is a great idea.

Adam

---

From: "Adam Barth" <[email-masked]>
Date: Mon, 12 Jan 2009 14:50:52 -0800

In taking to server operators, bandwidth was a major concern.  There
are lots of ways to fix this problem (and the similar sibling domain
issue).  We should aim for a solution that minimizes bandwidth.

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 12 Jan 2009 23:54:07 +0100 (CET)

On Mon, 12 Jan 2009, Bil Corry wrote:

> Of course, we're reworking the cookie spec, so presumably we can choose a 
> better method (which may be the Cookie-Integrity header).

Personally I would like to see this effort produce a document for the current 
cookie practises. Clearly new cookie specs have a very hard time to get 
accepted so just starting a third or forth cookie spec that nobody will adopt 
isn't very useful. IMHO.

> Because of the limited deployment of Cookie2, I'd imagine any backwards 
> compatibility problems would be also limited.

If a new spec is being written anyway, why re-use something that can cause 
problems? In fact, it wouldn't even have to use the name 'cookie' but could 
just as well use 'state' or something else.

-- 

  / daniel.haxx.se

---

From: "Blake Frantz" <[email-masked]>
Date: Mon, 12 Jan 2009 17:58:32 -0500

> overwriting the Secure cookie.

If the user agent treated two otherwise equal cookies from disparate
schemes distinctly then the attacker must control content in the HTTPS
scheme to impact the integrity of the Secure cookie. This assumes that
the Secure cookie was set over HTTPS - which I think is safe. From what
I've read in section 6.2 of the paper you've referenced, the attacker
requirements to compromise the integrity of the Secure cookie are
equivalent with the approach I'm seeking feedback on. Those requirements
being control of content rendered in the HTTPS scheme.

> http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf

Nice work. In support of this, it *may* be beneficial to modify existing
XHR mechanisms such that they prevent the programmatic creation of a
Cookie-Integrity header (http://www.w3.org/TR/XMLHttpRequest/#security).
I haven't thought through this entirely, though. 

> legitimately overwrite Secure cookies over HTTPS (for example, during

The cross scheme clobber prevention I'm attempting to get feedback on
does not break this use case.

My take away from this is that you see a need to protect the integrity
of Secure cookies, where possible. I agree with this. I'm not convinced
that treating cross-scheme cookies distinctly or adding Cookie-Integrity
header is or is not the solution to the problem. For the purpose of this
group, I think we may have identified another bullet item in the list of
things to accomplish - figure out the best way to protect the integrity
of Secure cookies.

Blake

---

From: "Adam Barth" <[email-masked]>
Date: Mon, 12 Jan 2009 15:08:37 -0800

On Mon, Jan 12, 2009 at 2:58 PM, Blake Frantz <[email-masked]> wrote:

(out of order)

> For the purpose of this

I'm not an expert on what is or is not in scope for this working
group, but I think its important to protect the integrity of Secure
cookies.  Most people fall out of their chair when they realize Secure
cookies lack integrity.

(Further comments for those interested in the details of this discussion.)

> scheme to impact the integrity of the Secure cookie.

While technically true, this doesn't actually help in practice because
Secure and non-Secure cookies are serialized identically in the Cookie
header, make it impossible for the server to tell whether the cookie
was set over HTTP or HTTPS.

> I haven't thought through this entirely, though.

XHR has a generic generic namespace of headers that can't be set by
script: those that begin with "Sec-".  We could simple name the header
"Sec-Cookie-Integrity" if we want this behavior.

> does not break this use case.

Oops.  Typo.  I meant "overwrite Secure cookies over HTTP (for
example, during logout)."  We could gather data how often this occurs,
but I suspect many sites that use both HTTP and HTTPS store auth
credentials in a Secure cookie, which they delete with an HTTP request
upon logout.

Adam

---

From: "Blake Frantz" <[email-masked]>
Date: Mon, 12 Jan 2009 18:40:16 -0500

> was set over HTTP or HTTPS.

I see what you're a saying. However, if the user-agent actively asserts
"the integrity of these cookies is preserved" or the server operates on
the assumption that the cookie it previously set over HTTPS did not get
overwritten via HTTP (much like servers currently assume the user-agent
implements the same-origin policy), the server is still in the same
position - it must trust what the user agent is telling it with respect
to cookie integrity. 

> "Sec-Cookie-Integrity" if we want this behavior.

Good idea. 

> example, during logout)." 

Ah, yes, I agree this use case would break. Though, I don't think I've
encountered many, if any, instances of this. That surely doesn't mean a
million of them don't exist :)

Blake

---

From: "Blake Frantz" <[email-masked]>
Date: Mon, 12 Jan 2009 18:43:55 -0500

> $Domain, $Path and $Port attributes.

It's my understanding that these attributes are used to determine where
the user agent should send the cookie to, not make decisions on where an
existing cookie can be overwritten from. Parity between these polices
("send cookie to" and "write cookie from") would probably be best.

Blake

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Tue, 13 Jan 2009 01:21:53 +0100

On Tue, 13 Jan 2009 00:43:55 +0100, Blake Frantz <[email-masked]>  
wrote:

> the user agent should send the cookie to,

Not just that.

Clients are also required by RFC 2965 to send $Domain, $Path and $Port to  
the server for each cookie whenever the associated Domain, Path and Port  
parameters were used in the Set-Cookie2 header so that the server can pick  
the right one when multiple cookies have the same name.

My point about $Port is that if the server used either 'Port=' or  
'Port="443"' and checks for the $Port whenever the cookie is received, it  
will be able to detect if an unsecure server clobbered it, because that  
server would either have to use 'Port="80,443"', or not use Port at all,  
to be able to set the cookie and to get the cookie sent to the secure  
server. The receiving server will not be able to detect if a compromised  
secure server clobbered the cookie, but the $Origin field I am suggesting  
should handle that as long as the receiving server itself hasn't been  
compromised.

-- 
Sincerely,
Yngve N. Pettersen

---

From: "Adam Barth" <[email-masked]>
Date: Mon, 12 Jan 2009 16:55:16 -0800

On Mon, Jan 12, 2009 at 4:21 PM, Yngve N. Pettersen (Developer Opera
Software ASA) <[email-masked]> wrote:
> server would either have to use 'Port="80,443"', or not use Port at all, to
> be able to set the cookie and to get the cookie sent to the secure server.

We're asking for integrity against an active network attacker (imagine
someone who poisons DNS).  The active network attacker can spoof an
HTTP server on port 443, i.e. http://www.bank.com:443/.  When that
fake server responds with Set-Cookie2, it can cause the Port attribute
to be set to 443.

> The receiving server will not be able to detect if a compromised secure
> server clobbered the cookie, but the $Origin field I am suggesting should
> handle that as long as the receiving server itself hasn't been compromised.

Yes, the Origin attribute should fix the issue as long as it includes
the scheme (and not just the domain and port).

Adam

---

From: "Adam Barth" <[email-masked]>
Date: Mon, 12 Jan 2009 16:58:17 -0800

> position - it must trust what the user agent is telling it with respect

I don't understand what you mean by "actively asserts."  My point is
that a browser cannot do this with the current headers without a
unbounded amount of storage.

> million of them don't exist :)

How would you know if you've encountered instance of this pattern?  In
any case, we can instrument a browser and collect data if we want to
know how common this is.

Adam

---

From: "Blake Frantz" <[email-masked]>
Date: Tue, 13 Jan 2009 11:14:09 -0500

> unbounded amount of storage.

When the user agent sends a Content-Integrity header it is actively
asserting the cookie's integrity level. Regarding storage, we've gone
full circle on this one. I'm thinking our time might be better served if
we spent 15 mins on the phone to talk this through. That, or shoot me
additional information on the storage-based implications you are
referring to. I would appreciate the education. If you have some time to
discuss this, give me a call any time at (206) 384 3023 or shoot me your
number and a good time to call you.

> How would you know if you've encountered instance of this pattern?  

I would have hopefully logged an improper session termination bug
against one of the sites I had performed security testing on. If the
logout handler operates over HTTP and the session ID is stuffed in a
Secure cookie then the logout handler would have no idea which session
it should terminate because it would not have access to the session ID.
This would result in a lingering session. I don't recall writing about
an improper session termination bug that was manifest due to the logout
handler being exposed over HTTP vice HTTPS. Again, my experience does
not mean this pattern isn't implemented all over the place.

Blake

---

From: Dan Winship <[email-masked]>
Date: Tue, 13 Jan 2009 12:11:30 -0500

Adam Barth wrote:
> group

We're not actually a working group yet, so we don't have a charter, so
nothing is specifically in or out of scope yet.

The deliverable that some people want is an Informational RFC explaining
how cookies are actually used *right now* (as opposed to "how we wish
they worked"), with notes on areas of incompatibility, and discussion of
known security problems.

If we want to actually make cookies better, then we need to be careful
to not just create yet-another-improved-cookie-spec-that-everyone-
ignores (as Daniel Stenberg already noted). So there are two kinds of
things we can do:

    * Find ways to make cookies better that don't require web developers
      to change their behavior. (Eg, draft-pettersen-dns-cookie-validate
      and draft-pettersen-subtld-structure.)

    * Find ways to make cookies better that we can somehow force/trick/
      bribe web developers into using.

One way to make the new spec compelling might be to add some feature
that would be needed by some other useful spec like
Cookie-based-HTTP-auth (draft-broyer-http-cookie-auth, currently being
discussed on the ietf-http-auth list). Or to have new cookies integrate
with HTML5 in some exciting way that old cookies wouldn't be able to.

Likewise, even though it would be cleaner to scrap Set-Cookie and
replace it with a new header a la Set-Cookie2, developers are going to
want backward-compatibility, and don't want to have to set each cookie
twice (for bandwidth reasons), so the best solution for new features may
be to add new attributes to Set-Cookie (keeping in mind that old
implementations would still see the cookies but would ignore the new
attributes).

-- Dan

---

From: "Blake Frantz" <[email-masked]>
Date: Tue, 13 Jan 2009 12:33:55 -0500

> Sent: Monday, January 12, 2009 4:55 PM

...

> fake server responds with Set-Cookie2, it can cause the Port attribute

If the user agent truly believes that evil.com is bank.com then all bets
regarding cookie integrity are off - absent an HMAC or something
equivalent. 

> the scheme (and not just the domain and port).

I agree with Adam and Yngve regarding the Origin attribute. The only
things I would add are:

	1. The user agent must not leverage information provided to it
from the server when constructing the Origin value. 
	2. The user agent must not derive the scheme from the port
number.

Blake

---

From: Bil Corry <[email-masked]>
Date: Tue, 13 Jan 2009 21:23:43 -0600

> they worked"), with notes on areas of incompatibility, and discussion of

We have to do this anyhow if we want a spec that will actually be used by the browser vendors.  Without it, we will not have any visibility to the impact our new spec will have on those who have to implement it, and our decisions will be unguided by reality.

> If we want to actually make cookies better,

We do.

> then we need to be careful

I don't think the first option will work; how many sites *still* do not use the Secure or HTTPOnly flags?  We have an education campaign in front of us no matter what we decide to do, so option two appears to be our fate regardless.

> with HTML5 in some exciting way that old cookies wouldn't be able to.

We definitely should consider including draft-broyer-http-cookie-auth, and integrate Yngve's improvements as well.  My own personal desire is to see cookies offer three protections for Secure/HTTPOnly cookies:

(1) Confidentiality - using Secure/HTTPOnly to guard the contents of cookies.

(2) Integrity - protecting Secure/HTTPOnly cookies from clobbering/eviction/replacement.

(3) Privacy - protecting Secure/HTTPOnly cookies from even being discovered if it exists from an outside source.

In a world free from legacy, I'd even suggest Secure is the default for any cookie sent over HTTPS unless otherwise specified (NonSecure flag?), and HTTPOnly is the default for all cookies unless otherwise specified (Scriptable flag?).  That's why I had the thought of re-purposing Cookie2, changes like those could be made with little impact (an unqualified assumption).

> implementations would still see the cookies but would ignore the new

If the browser advertises that it supports the new cookie spec (Cookie2?), then the server could choose which Set-Cookie header to return.  Now that will add yet another header from the client, but I think another client header is needed anyhow for technologies such as Content Security Policy to advertise itself[1].  So I'd imagine something like:

	Accept-Language: en-us,en;q=0.5
	Accept-Encoding: gzip,deflate
	Accept-Charset: UTF-8,*
	Accept-Headers: Set-Cookie2,X-Content-Security-Policy

- Bil

[1] Content Security Policy - http://people.mozilla.org/~bsterne/content-security-policy/

Note that there's been some debate over whether CSP should advertise itself, and at this point in time, no decision has been made.  The discussion about it is here:
http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/b2525aac8bda30cd