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

Dan Winship wrote on 1/13/2009 11:11 AM: 
> 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.

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

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.

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

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

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

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

_______________________________________________
http-state mailing list
http-state@ietf.org
https://www.ietf.org/mailman/listinfo/http-state