Subject: Introducing a Session header...

From: James M Snell <[email-masked]>
Date: Tue, 17 Jul 2012 15:48:05 -0700

In several of the ongoing discussions there has been mention of the need
for a Session header to replace the use of Cookies for basic session
management. For HTTP/2.0, this seems like a straight forward and smart
thing to do. To start it off, let's define a new header whose value is a
variable length token.

Within HTTP/1.1, it would be something like "Session:
some-random-string-of-letters"

If we go with the current SPDY header structure, the header name should be
something like ":session".

If we ended up using the binary encoded headers I've suggested, the session
could be encoded as:
  [0, 10, 1, 0, 29, 's', 'o', 'm', 'e', ... ]

The semantics would be simple: the Session header can be set by the Client
or Server and communicates the Session identifier for the Stream. Each
Stream can have exactly one Session identifier. The current Session
identifier in a stream can be changed by sending a new Session header. To
resume a session, the Session header would be added to the SYN_STREAM.

Obviously this does nothing to address the security issues but it, at the
very least, should help us to reduce the reliance on cookies.

- James

---

From: Ross Nicoll <[email-masked]>
Date: Wed, 18 Jul 2012 00:08:17 +0100

Definitely a fan of the idea in principle, butŠ

> Session header can be set by the Client or Server

I can't see a situation in which we want the client dictating a session; a
session should only be started by the server, and only once a session has
been created by the server should the client provide the header on later
streams.

On which note, there's further controls I think we would need; some way of
indicating session maximum lifespan (for example a banking site may want
sessions to expire after 15 minutes even if the browser is now closed) and
scope (for example domain, host, specific paths on host, single URL) are a
must. Security requirements may need to be indicated (TLS only, connections
with a minimum key size, something else)? The ability for the server to
indicate a session is unknown (essentially a mild error case) could be
useful.

There's also the question of logging out; obviously the server could just
forget a session, but it may be useful for it to indicate to the client that
the session is being dropped and should be forgotten. We may also want to
suggest user agent UI options for logging out (so that there's always a
consistent logout option irrespective of the site).

I'd also be tempted to tighten the definition of a session identifier, to be
a UUID. This may make backwards compatibility trickier, but I think would
encourage use of difficult to guess identifiers by developers who may
otherwise simply hand out sequence numbers, without knowing better.

Thoughts?

Ross

From:  James M Snell <[email-masked]>
Date:  Tue, 17 Jul 2012 15:48:05 -0700
To:  <[email-masked]>
Subject:  Introducing a Session header...
Resent-From:  <[email-masked]>
Resent-Date:  Tue, 17 Jul 2012 22:49:02 +0000

In several of the ongoing discussions there has been mention of the need for
a Session header to replace the use of Cookies for basic session management.
For HTTP/2.0, this seems like a straight forward and smart thing to do. To
start it off, let's define a new header whose value is a variable length
token.

- James

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Jul 2012 16:21:16 -0700

> a Session header to replace the use of Cookies for basic session management.

Just because everyone does it and wants it, it doesn't mean that it is
suddenly a good idea.

It might end up being a necessary idea, but don't mistake necessary
for good or for compatible with the architecture of HTTP.  If
something like this happens, the goal should be to minimize
crappiness.

All this looks like so far is a constrained syntax Cookie, which is
far less useful than a Cookie and so I see no reason for it to be used
over a Cookie, which you will have to support anyway...

--Martin

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Tue, 17 Jul 2012 16:28:08 -0700

FWIW many browsers are in the midst of trying to get rid of the notion of a
"session". What does it mean nowadays? If we need to restart the browser to
apply a security update, why should that end a session if we restore the
tabs that the user had open? What does a session mean on mobile, or for
users who leave tabs lingering for a long period of time?

I think it's safe to say we would prefer to axe the notion of "sessions"
rather than further propagate it.

-Ian

On Tue, Jul 17, 2012 at 3:48 PM, James M Snell <[email-masked]> wrote:

> If we ended up using the binary encoded headers I've suggested, the
> session could be encoded as:

---

From: Dirk Pranke <[email-masked]>
Date: Tue, 17 Jul 2012 16:45:08 -0700

I think you/we need to be clear(er) about what you mean by "session",
because I suspect there are several different meanings floating around
in this thread.

-- Dirk

On Tue, Jul 17, 2012 at 4:28 PM, Ian Fette (イアンフェッティ) <[email-masked]> wrote:
>> management. For HTTP/2.0, this seems like a straight forward and smart thing
>> to do. To start it off, let's define a new header whose value is a variable
>> length token.
>>

---

From: James M Snell <[email-masked]>
Date: Tue, 17 Jul 2012 16:49:58 -0700

This moved off list unintentionally...

---------- Forwarded message ----------
From: James M Snell <[email-masked]>
Date: Tue, Jul 17, 2012 at 4:48 PM
Subject: Re: Introducing a Session header...
To: Martin Thomson <[email-masked]>

This, without question, would be the right approach... assuming we can
successful move people away from using sessions as a whole. The main
motivation for me on this is making it more efficient to package and
process the bits necessary for basic header operation. If we can drop
session-based routing from the picture, then fantastic.

(While we're at it, can we also eliminate routing based on the request-uri?)

On Tue, Jul 17, 2012 at 4:44 PM, Martin Thomson <[email-masked]>wrote:

> On 17 July 2012 16:27, James M Snell <[email-masked]> wrote:
> > I certainly do not disagree. So, given this strawman, and assuming the
> goal
> > is to constrain crappiness and make things easier for http routers to do
> > their job in the process, what would be a better approach to start from?
>
> I think that Ian has it right.  The most sensible approach is to avoid
> entering the quagmire altogether.  By necessity, we will be able to
> transport cookies and people with therefore continue to use them.  For
> everyone else, don't encourage new abuses of the protocol.
>
> BTW, I'm seeing moves to avoid and even remove stateful routing of
> HTTP.  I work with Azure a lot now and the load balancers there
> purposefully round robin requests with no sessions, cookies, or any
> sort of stickiness.  It's a bold move, the right move, and not one
> that they would have gotten away with 5 years ago.  The world is
> slowly learning.
>
> --Martin
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Jul 2012 16:56:26 -0700

> This moved off list unintentionally...

Ahh, oops.  I thought it was intentional.

> assuming we can successful move people away from using sessions as a whole

Who are you trying to kid?  Cookies are here to stay.  It's just that
anyone with any sense will avoid them.

> (While we're at it, can we also eliminate routing based on the request-uri?)

Why would you ever want to do that?  That's an important feature.  At
least it is stateless.

---

From: James M Snell <[email-masked]>
Date: Tue, 17 Jul 2012 17:04:27 -0700

> anyone with any sense will avoid them.
Yes... sadly, I know. One can dream.

> Why would you ever want to do that?  That's an important feature.  At

A variety of reasons, really, but nothing that's likely to sway any
opinions ;-) ... by far the more important thing is: IF session-based
routing continues to be a "feature", we should do what we can to break to
reliance on cookies (as much as possible anyway). If, however, the general
movement is (quite thankfully) away from session-based routing, then
beautiful, I'm happy.

- James

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 18 Jul 2012 10:14:08 +1000

James et al,

Just a reminder: We're not here to re-define the semantics of HTTP; our current charter is about how it goes across the wire. We can talk about HTTP semantics on this list (and often do), but let's not get confused about the scope of the current discussion.

I know that it's tempting to say "we're doing HTTP/2, let's throw this in...", but if we start doing that, we're never going to finish. Let's stay focused. Replacing Cookies is NOT a small task.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Tue, 17 Jul 2012 17:44:16 -0700

On Tue, Jul 17, 2012 at 5:14 PM, Mark Nottingham <[email-masked]> wrote:

> James et al,
>
> Just a reminder: We're not here to re-define the semantics of HTTP; our
> current charter is about how it goes across the wire. We can talk about
> HTTP semantics on this list (and often do), but let's not get confused
> about the scope of the current discussion.
>
>
Hmm.. I'm not sure I see how discussion about the potential use of optional
headers qualifies as "re-defining the semantics of HTTP".

> I know that it's tempting to say "we're doing HTTP/2, let's throw this
> in...", but if we start doing that, we're never going to finish. Let's stay
> focused. Replacing Cookies is NOT a small task.
>
> Cheers,
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 18 Jul 2012 10:52:02 +1000

On 18/07/2012, at 10:44 AM, James M Snell wrote:

> Hmm.. I'm not sure I see how discussion about the potential use of optional headers qualifies as "re-defining the semantics of HTTP".

Re-defining, or adding to them in orthogonal ways. A session header can be a separate effort; there's no reason (AFAICT) to tie it to the protocol version. 

Cheers,

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 18 Jul 2012 12:52:09 +1200

On 18.07.2012 12:04, James M Snell wrote:
> On Tue, Jul 17, 2012 at 4:56 PM, Martin Thomson wrote:
>
>> On 17 July 2012 16:49, James M Snell wrote:
>> > assuming we can successful move people away from using sessions as 
>> a
>> whole
>>

What I'm getting from this thread is that the proposed "session" is 
just an identifier for some client context.

Essentially meaning a message from the client "I've created a context, 
any context you create for this request needs to associate with this 
ID".

The server is still free to create a traditional Session (or not) at 
its end. Using a different key entirely, just translate from server key 
to client key when talking to the client - and hey thats actually safer 
than todays session cookies. But first-party Cookie data and whatever 
state can be pushed back to the client for inclusion into that context 
without introducing ever-cookie issues around expiring a bunch of 
unassociated data.

NP: If/when this header gets defined it *will* have to traverse 
HTTP/1.x connections so please make the ABNF: 1#(token / quoted-string) 
[';' ... ]

AYJ

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 17 Jul 2012 20:23:47 -0400

I would like to have a strong session cookie. That is a session cookie
that is bound to some shared secret and a protocol that allows the
client to provide a proof of knowledge of the secret with each
request.

The reason for this is that once the client has performed an initial
authentication to the service (via password, OAUTH, OpenID, sheeps
entrails, whatever) it can re-authenticate at very low cost on every
successive request.

This would be in addition to any authentication mechanism provided by
TLS since TLS authentication is typically client authentication of the
server and that is not server authentication of the client.

This does not solve the HTTP authentication problem but it does break
off a significant chunk for separate work.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 18 Jul 2012 10:14:59 +0900

> over a Cookie, which you will have to support anyway...

Well, yes. Some Web Application Frameworks (e.g. Rails) already use only 
a single cookie as a session identifier.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 18 Jul 2012 10:16:13 +0900

> otherwise simply hand out sequence numbers, without knowing better.

Yes. Or simply stick the cookie dough into the Session header :-(.

Regards,   Martin.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 18 Jul 2012 08:12:51 +0000

In message <CABP7Rbf6n1=[email-masked]>

>some-random-string-of-letters"

I would actually make it more restricitve:

	Session-ID: <32-64 hex digits>

(In HTTP/2.0 it should of course be transmitted in raw binary)

And I would make the first bit indicate the scope:

	0: This Session-ID is anonymous, I have no idea who the user is.
	1: This Session-ID represents a user I have identified locally.

The remaning bits have no meaning outside the user-agent, but are merely
a (mostly!) unique identifier, usable to refer to a session.

Public User-Agents, in libraries, cafes and so on, should be
configured to always send '0' sessions, and should put random bits
in the rest of the session-id, as should any user-agent asked to
operate in anonymous mode.

User-Agents working on behalf of a single person (at a time) can,
at the users discretion, always send the same 1-session id to a
particular site, in order to offer the user "persistent sessions"
only subject to occational authentication.

Abstractly I do agree that it would be wonderful if both client and
server could be stateless, but I don't see how that could ever work
for a bank ?

And yes, I really mean it when I say that HTTP/2.0 should not support
cookies, because they are a major eater of time, caching efficiency and
consequently bandwidth.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Philippe Mougin <[email-masked]>
Date: Thu, 19 Jul 2012 21:21:27 +0200

Some of you are suggesting introducing a Session header. In your reasoning, how do you take into account the following points? 

- HTTP was designed with the idea that there is no application state (i.e., session state) stored on the server. This provides a number of architectural benefits.

- Furthermore, not having session state stored on the server is a constraint for creating Restful systems.

- Finally, given a design that stores session state on the server Restafarians can usually show you an equivalent design that does not.

Thanks.

Philippe Mougin

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 19 Jul 2012 20:48:01 +0000

In message <[email-masked]>, Philippe Mougin writ
es:

>- HTTP was designed with the idea that there is no application state 
>(i.e., session state) stored on the server. This provides a number of 
>architectural benefits.

That might have been the idea, but it is certainly not the (only)
practice today.

In fact, many appearantly server state-less sites, uses load-balancers
to direct the client to the same server all the time, in order to
benefit from database and VM caching of ... session-relevant state.

I think that HTTP/2.0 should serve all relevant contemporary and
future needs, and be less concerned about what ideas somebody had
or didn't have 20 years ago.

And after all, nobody is proposing that HTTP/2.0 make the server
state-less model impossible to implement.

I won't claim that the original idea could not have survived as the
sole model, but if so, cookies should have been killed as a concept
before it became the festing pile of state-poo they have become.

The fact the EU has felt it necessary to legislate what cookies can
contain and what they can be used for, should not be overlooked
here.  HTTP/2.0 can and will be scrutinized in Bxl for compliance
with EU privacy and cookie directives.  Being proactive might pay off.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 19 Jul 2012 23:36:30 +0200

> benefit from database and VM caching of ... session-relevant state.

I would go further, because after some thinking I don't agree with
the requirement of *a* session header. The web is so stateful nowadays
that multiple layers generally need their own session information.

Requests coming from clients to servers sometimes flow across multiple
places and a single session identifier is not always enough, sometimes
a few ones need to be provided.

I think it would be terribly useful to have a session container in which
we can store one or more session identifiers and that load balancers and
servers can easily access and manipulate.

I also note a warning from someone here (sorry I forgot who it was) who
reminded us that smartphones and tablets have always-on browsers that
are never closed, and thus the session is something hard to define,
probably just a browsing context.

> before it became the festing pile of state-poo they have become.

It was too late. The biggest issue with the cookie mess is that the
same entity is used for storage and for session identification. We
don't want to *store* anything in something that is used to identify
only.

Willy

---

From: David Morris <[email-masked]>
Date: Thu, 19 Jul 2012 15:33:20 -0700 (PDT)

> servers can easily access and manipulate.

It is also critical that any session header concept address the scope of 
applicability of a session identifier so that the user agent can
accurately and efficiently determine whether a particular session
applies to each request. There is a lot of experience embodied in
the our group history re. cookies and authentication, expiration, etc.

I see no reason for a browser generated session id independant of a
server's desire to receive one. And getting the related issues
like scope and expiration solved in a secure way would still seem
to require properties controlled by the server and not the client.

Dave Morris

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 19 Jul 2012 22:36:13 +0000

>servers can easily access and manipulate.

At this point I would like to defer to card-carrying cryptographers,
because while I think nobody but the client should be allowed to
define/change the session identifier, in order to shut out spoofing
of it, I don't trust my own analysis of this question to be definitive.

I do think it would be terribly useful if the session-id was client
originated and contained a anon/specific-authenticated-user bit,
because that would warn the server about public PCs etc.  So even
if we don't do the session-id, I think I would advocate that bit
on its own.

---

From: David Morris <[email-masked]>
Date: Thu, 19 Jul 2012 15:53:54 -0700 (PDT)

> like scope and expiration solved in a secure way would still seem

Also, proxies should also be able to assign 'session' identifiers
with sufficient scope identity what such identifiers could be
reliabily removed before forwarding the next request to an
origin server.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 19 Jul 2012 23:01:20 +0000

In message <[email-masked]>, David Morris 

>to require properties controlled by the server and not the client.

We are not talking about properties, only about identity of the session.

It should be the user, and only the user who decides when a session
starts and ends, so it has to be the user-agent which controls the
session-id.

The server is of course free to ignore the session-id from the client,
and implement its own concept of a session.

But HTTP/1.x lacks a way for the user to communicate his intent
with respect to sessions, and we should remedy that in HTTP/2.0

---

From: David Morris <[email-masked]>
Date: Thu, 19 Jul 2012 16:34:27 -0700 (PDT)

> with respect to sessions, and we should remedy that in HTTP/2.0

We clearly arean't talking about the same concept. 

In my definition and experience, the end user
rarely has any notion of what a session might be and hence no
way to understand when and why to interact with the browser
to effect control of the session.

"Session" is a relationship between a user/browser and a web
application. Only the application has any knowledge of its
composition.

The user end of a session is generally represented by a single
computing system and may include multiple windows, tabs, etc.
The applicatation will range from a single instance on a
shared host up and through many hosts distributed between
physical locations.

>From the browser/user interface perspective, a 'logout'
function could mean close all windows/tabs associated with
this session identifier, flush the cache and cookies
associated with this session and notify the application
server that the logout was invoked.

I deal with many average web users and am convinced that
placing any burden on them to define the bounds of a session
would be a colossal failure.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 20 Jul 2012 07:44:13 +0200

> of it, I don't trust my own analysis of this question to be definitive.

Yes you're right that if the client builds it by itself, the ID cannot
be injected. However it can still be stolen and reused. But at least
the easiest part of the security failure with cookies would be covered.

> if we don't do the session-id, I think I would advocate that bit

Based on your first point above, I think that the client could build
*part* of the ID. If the client generates a 64-bit random for instance,
it doesn't ensure unicity, which is a server's task, but it saves it
from being injected another ID. So from the server's point of view,
a client could be identified by the couple of (ID1,ID2) where ID1 is
invented by the client and unknown from JS and ID2 is invented by the
server.

We could then even keep cookies as they are for ID2, and just use a
new identifier for ID1. That way we remain compatible with HTTP/1
(important goal) and HTTP/2to1 gateways can pass ID1 into a header
field that the server can use.

If we do something like this, then it is wise to make this ID part
of the protocol, just like the mask is part of the protocol in
websocket without being accessible to the client's stack.

This needs more thinking in my opinion but I think it's worth it.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 20 Jul 2012 07:52:39 +0200

> to effect control of the session.

It's not entirely true, because right now cookies are systematically
sent to same origin server, from the same window (depending on browser)
and until the browser is closed. A session might more or less be defined
as a series of pages accessed by consecutive clicks keeping you on the
same origin server. I think the browser guys would have a much more
detailed description of the algorithm and of the issues they're facing.

> application. Only the application has any knowledge of its

Each side has since it's a relationship. The client just knows it
carries an opaque thing at the moment.

> would be a colossal failure. 

I don't think we have to change the experience for them, it's
important that it is transparent. Basically the condition for a
browser to generate a new session ID could be "did I already have
an ID for this site". It remains compatible with how session cookies
work.

Note that I'm not advocating for leaving it all to the browser (see
my other mail in this thread), because the server side only knows
what it needs to put there (eg: server identifiers for multi-site
load balancing farms).

Regards,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 20 Jul 2012 18:35:54 +1200

> the easiest part of the security failure with cookies would be covered.

This is where server-side management of its own session steps in.

We have both server and client state to deal with in reality. So far the 
server generating a UUID and sending it to the client (over insecure 
third-party links) has proven insecure to the point of being a joke.

Client-generated session ID, is just a key / salting value. That gives 
us a couple of things:
  1) client can ensure that it is unique (at least relative to any other 
one they generate) over some long time period
  2) client can maintain multiple sessions to the same server simultaneously
  3) client can share session ID between software on their own machine 
(ie several browser tabs, or a browser tab and some independent 
credentials manager software)
  4) client can implement do-not-track by omitting the session ID from 
any request, OR changing it frequently, OR sending some max-age property 
for expiry.
  5) client can "logout" at will by erasing the state associated 
(possibly informing the server, but not necessarily)
  6) limited meaning - simplicity leads to better security through 
easier understanding and thus correct use.
    Making it mean just "here is a reference ID to the data I have on 
you" is simple.

The server can not be expected to rely on that session ID alone as any 
kind of UUID. They need to be able to assign session based on that ID 
*plus* any other information they have available to guarantee the 
uniqueness (client IP, channel number, socket number, UA header, phase 
of the moon, whatever)

  1) server can use it as a salting value to uniquely identify the 
separate client sessions. IFF, the server uses additional data to 
generate the session.
  2) server can track the session across any requests regardless of 
delivery method (relative to what the server tacks on as extra key bits 
for its own end - this also determins/limits theft of session-ID key risk).
  3) middleware can play to its hearts content, altering session IDs to 
new values. They mean nothing but opaque blob to the recipients end, 
worst case is fail-closed if they are used for anything security related.

What we have in abstract is a shared session between client and server, 
where those client/server endpoints may be any number of Federated 
softwares or machines. Each end has its own state, which may or may not 
be conveyed over the links, but for best security only the algorithms 
(.js) and data (.html, .xml, .css, ...) would transfer.

When you get down to the basics of this, it sounds a bit like the OAuth 
Bearer token (login federated between clients) or the Digest nonce 
"session" mode (client-driven ID). PKI abstract design at its finest. 
(Now the card-carrying cryptos will step up and hammer this non-card 
carrying one for obvious mistakes).

> invented by the client and unknown from JS and ID2 is invented by the

Exactly. Neither end being required to complete the session, or even to 
inform what its internal session ID key (or even algorithm) is.

> field that the server can use.

IMO, we can ignore Cookies as headers for all of this. Sessions in 
Cookies are already largely the provence of web servers and if servers 
and browser roll out the new session they will be able to drop use of 
session-cookie cleanly when Session-ID no longer needs to be 
encapsulated inside one.

Cookies as used for data transfer is a different problem entirely and 
should not be tackled by the creation of a session state semantics. 
Simply removing the credential-like identifier from Cookie will go a 
long way towards clearing up the mess.

> This needs more thinking in my opinion but I think it's worth it.

+1 on both counts.

Amos

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 20 Jul 2012 09:02:37 +0200

> Client-generated session ID, is just a key / salting value. That gives 

I agree, this is equivalent to salting.

>    Making it mean just "here is a reference ID to the data I have on 

OK.

> uniqueness (client IP, channel number, socket number, UA header, phase 

Warning when you're saying this, some of these info are neither stable
nor unique to the client, they provide low value when building an ID.

> worst case is fail-closed if they are used for anything security related.

It's not as simple : if we want it to be simple for both ends, ideally
a fixed-length well-defined ID is fine. However its use will be too
limited (middleware cannot rely only on "learning" IDs, they need to
put deterministic information there such as server identifiers when
performing load balancing between multiple DCs, DMZ, ...).

If we have a variable-sized ID that intermediaries can fiddle with,
then it's harder to put that in the protocol and we risk seeing it
degraded as cookies to put whatever in them.

Maybe we need a specific part for routing information, but I'm really
not convinced this is needed. I think in fact that the client-generated
ID should be fix-sized and always present, and that the server-generated
part could be variable with a limited size so that it is not abused
anymore.

> be conveyed over the links,

Wait a minute, a few times in this thread I felt like there was an issue
here, it's important to keep in mind that there is not a single-end on the
server side. Servers are often split between multiple machines, multiple
DMZ, multiple areas, multiple DCs for a single client session, and with
various possible paths between them without the client ever being aware
of it. It's important because there is not an "own state" as called here,
but a global state made of many independant states.

(...)
> session-cookie cleanly when Session-ID no longer needs to be 

Only when the session-id is able to convey as much information as is
needed to route the request to its target. Right now cookies are used
*a lot* for this. I know some places where there are up to 6 layers
of server farms with multiple possible paths between them (think many
portals for similar access to same information), and the only way to
know where to pass through is to use the information inserted by LBs
into cookies. To completely get rid of cookies we need to be able to
store this routing information somewhere else (I would love this, so
that we don't have to deal with this horrible cookie header anymore).
But this is not a small issue to deal with.

> should not be tackled by the creation of a session state semantics. 

Cookies are even more generic, they're just a copy of opaque data the
server needs when the client gets back. Originally it was just a way
to find the pointer to the session (which is routing information as
well after all). But they were completely abused to carry anything
everywhere and the first issue is that JS has access to them.

> long way towards clearing up the mess.

Agreed!

Willy

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 20 Jul 2012 20:20:33 +1200

> nor unique to the client, they provide low value when building an ID.

That is intentional.
The server determines these values, so has control over how much it 
trusts the client, indeed how it defines "client", for portability of 
the session state at the server end. ie whether to protect against 
replay attacks, mobility support, future P2P facebook network.

That bank you work for would likey want to prevent clients moving 
country within a session. Google search may not care.

All the benefits we currently enjoy with server-sessions are retained. 
Along with this extra security from salting to uniquey identify the 
client end-point.

> performing load balancing between multiple DCs, DMZ, ...).

Why can't server identifiers be associated with learnt IDs? What is 
learning apart from the LB playing server with its session-state 
containing a pointer at another server which does the donkeys work 
(using the same session-ID, OR a new one from the LB generated for the 
unique client).

> part could be variable with a limited size so that it is not abused

To prevent mis-use the way cookies were I agree.

Do we have any data on how many systems are abusing session-cookie IDs 
and the equivalent to encode data over the wire?
Given that we are not burning Cookie at the gateway (using it for data 
transfer is easier), what is the actual risk here?

> but a global state made of many independant states.

Understood. I have been working from that viewpoint.
IFF the servers federate behind an LB they have the same shared session 
state - no problems with rleation to teh client and client connectivity 
(lag maybe but not HTTP protocol related).
If not, they have different state. They can all safely receive the same 
client session-ID since it is opaque to them, and no data is sent back 
to the client be receiving it. The servers responding with different 
session-ID makes it clear to the client when and where context shifting 
of the state at its end required.

Where I stop in this rabbit hole is at client determination of what to 
do when its got state and the servers its talking too keep changing. I'm 
hoping the browser people might be able to shed a bit of light that we 
can continue a bit further there.

> But this is not a small issue to deal with.

That is our discussions on where to take network-friendly request-ID 
field come in. Being separate from end-to-end session it provides enough 
hop-by-hop state and multiple request linkages to form a stateful flow 
out of a hierarchy with stateless input.

> everywhere and the first issue is that JS has access to them.

Aye. But to kill them we have to pull out their utility and provide 
easier tools for their users to work with. Killing them with efficiency 
as it were. One slice at a time.

Amos

---

From: Roberto Peon <[email-masked]>
Date: Fri, 20 Jul 2012 09:28:13 -0700

We're basically reinventing parts of the TLS handshake.

I don't want this to turn into TLS vs not TLS, just pointing out that
generating a shared nonce securely is something we already know how to do.

-=R

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 20 Jul 2012 16:56:03 +0000

In message <CAP+FsNcWPw6j68Y9g9HfAWxZu-83W4p1cX0OTd4Fngky=[email-masked]>

>generating a shared nonce securely is something we already know how to do.

It doesn't have to be secure, it doesn't even have to be unique, to
serve the role I'm looking for, all I want is that the user-agent
gives us a routeable id.

---

From: Roberto Peon <[email-masked]>
Date: Fri, 20 Jul 2012 10:24:52 -0700

There are a number of different requirements here, and a number of problems
that we're attempting to solve, and I haven't yet seen someone put them
together in a list so that the tradeoffs are easily established, especially
in the context of actually getting people to use the thing.

In the event we allow cleartext communications (not debating that here),
security for the nonce/session-id is an issue.

-=R

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 20 Jul 2012 17:29:28 +0000

In message <[email-masked]>

>security for the nonce/session-id is an issue.

It is no more an issue than security is for a URI or a Cookie.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 20 Jul 2012 19:53:32 +0200

> (using the same session-ID, OR a new one from the LB generated for the 

Because there are multiple paths. Learning is only usable in small
deployments where you only have one LB (or say a couple of with
fast synchronization). When you have LBs in multiple datacenters,
the traffic comes to any of them and you absolutely need any of
these LBs to find the proper server even if it's located on the
other DC. The most common case for this is when you rely on BGP
with multi-hosting. Most of the clients stay on the same site,
but a small part of them switch to another POP once in a while.
The inter-DC traffic is very low but exists and you absolutely
want this to work. And obviously you cannot enable multi-DC sync
at high connection rates, it does not scale at all.

A similar case exists with multiple portals relying on common
backends.

That's why it is absolutely mandatory to keep the ability for a
LB (say HTTP router) to insert routing information and to match
them. Otherwise I already predict what will happen, exactly the
same as with the original Set-Cookie header : users will find
tricks to be able to send a second and third ID and then the
protocol will again be a real mess.

> and the equivalent to encode data over the wire?

Well I can say that I had to support variable buffer size in haproxy to
enable some people to send requests as large as 32 kB due to 2-3 cookies,
some up to 8kB (the max that they managed to pass through Apache, making
them realize they might have been wrong).

> transfer is easier), what is the actual risk here?

The risk is to continue to send too many useless data, that's all. Better
be careful this time.

> can continue a bit further there.

Might help, yes.

> out of a hierarchy with stateless input.

I'm not sure to get what you mean.

> as it were. One slice at a time.

Agreed. I'm not speaking about addressing all issues at once, just to see
if we can define what a session is an how all the involved parties might
benefit from it, at least by limiting/avoiding the need to know the cookie
header field. Hopefully we could reach a situation where we can completely
get rid of the cookie header (eg: simply have a list of (VAR,VALUE) couples
for a session). But it's too early.

Regards,
Willy

---

From: Albert Lunde <[email-masked]>
Date: Fri, 20 Jul 2012 13:01:39 -0500

I think the question of routing to load-balanced servers is at the other 
end of the problem space from federated logins, but I feel I should call 
people's attention to the Shibboleth projects statements on why single 
logout was a bad idea in their context:

https://wiki.brown.edu/confluence/display/CISDOC/Shibboleth+and+Application+Logout+Best+Practices

https://wiki.shibboleth.net/confluence/display/SHIB2/SLOIssues

Shibboleth could function as a WebSSO protocol on it's own and was 
sometimes deployed that way, but with was designed to function in 
concert with a local WebSSO protocol, typically scoped per 
institution/identity provider.

Shibboleth and the commercial and free WebSSO systems I've encountered 
(CAS (layered on Kerberos), Sun Access Manager (which became OpenSSO)), 
all seem to use a nasty mess of cookies and dynamic html/JavaScript 
tricks, to achieve WebSSO.

SAML is pretty much designed to work within the limits of existing web 
browsers, though there was talk from time to about part of the Liberty 
Alliance being applicable to web services.

It's worth asking if there is a way to add features to HTTP that would 
make WebSSO easier to active without giving away too much in security.

Scope is a key problem. The "same origin" policy for things like 
cookies, applets, flash, has been recreated with different mechanisms 
for breaking it.

---

From: James M Snell <[email-masked]>
Date: Fri, 20 Jul 2012 11:18:43 -0700

Indeed, not to mention the fact that terms like "session" are painfully
overloaded. Collecting the list of requirements is a good next step, I
think, but we need to be clear on the language used to avoid further
confusion.

Today, the term "Session" can refer to:

1. The TCP / TLS Connection
2. The concept of routing "Stickiness"
3. Application-level state that persists across multiple http requests, and
multiple TCP connections.

Cookies, quite unfortunately, have been abused in a variety of ways to
implement #2 and #3, generally because there is no protocol-level mechanism
provided to support those cases, developers have largely just hacked it in.

So if we're talking about specific requirements, I would argue that we:

A. We need a protocol-level concept of a "Routing Token" to address #2. The
use of this mechanism is strictly to provide intermediaries with a method
of establishing a generally-persistent routing path for all requests
originating from the same client. This token is NOT intended to be used to
identify or access shared application state. In fact, it is questionable as
to whether this routing token should be visible to the application layer at
all. The token could, theoretically, be transmitted entirely in the clear
without risk of inappropriate disclosure of sensitive information. The one
caveat, however, is that there must be a mechanism to protect the integrity
of the token. For instance, a form a DoS attack could be carried out by
intercepting and changing the routing token, breaking the stickiness of the
route or redirecting traffic to an unintended destination.

B. While we need a more reliable Application-level mechanism to deal with
#3 (essentially an evolved form of the Cookie mechanism) it does not need
to be defined at the protocol level. This is something that can be done
orthogonally to any work being done within the protocol. That's not to say
we cannot make use of potential new capabilities of HTTP/2.0 to deliver
that "more reliable mechanism", just that we do not need to completely
define the mechanism within HTTP/2.0.

Reasonable?

- James

On Fri, Jul 20, 2012 at 10:24 AM, Roberto Peon <[email-masked]> wrote:

> There are a number of different requirements here, and a number of
> problems that we're attempting to solve, and I haven't yet seen someone put
> them together in a list so that the tradeoffs are easily established,
> especially in the context of actually getting people to use the thing.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Jul 2012 15:36:22 -0400

2012 is not 1992, quite a lot has changed since

* Server state is now cheap, but it remains difficult to scale.

If you have an service that will fit on one server then server side
state is cheap and plentiful. I just built a new machine with 16GB on
2 DIMMS for $98. If I was building a server I would automatically fill
it with 64GB just because I can.

Server side state is no problem at all until you have a service that
requires 64.00000001 Gb and then you are into a big problem. You can
go up to 256Gb with 32 threads for about $10K. But you have to use
registered memory which isn't even stocked at my favorite supplier.

So the ability to use a router to front end the system and offload
requests in a sensible fashion is a very big win here, it makes
deployment of applications that are inherently statefull very much
more practical. The lack of support in legacy browsers is not a major
concern to me as I can simply consider all requests without the token
to be one bucket of work and resign myself to having to one-off that
particular site.

* People use multiple browsers, state tends to be bound to account profiles.

Not so long ago it was fairly unusual for someone to have more than
one machine in daily use. Today it is absolutely routine. So  that
makes client selected state identifiers rather less useful than server
side so that the server has control over where the requests are being
directed. This is the reason that we want a session identifier rather
than relying on the source IP address.

* What is often required is a session authenticator rather than just
an account identifier.

It is a protocol design error to rely on confidentiality as a means of
protecting authentication data sent over the wire. A password exchange
scheme should establish knowledge of the password without disclosing
the password. In general an authentication scheme should demonstrate
knowledge of the authentication secret (preferably a cryptographic
key) without revealing it.

There are in fact two separate authentication concerns in HTTP:

1) How does the service determine that Alice is making the request on
behalf of 'alice' at the start of a session?

2) How does the service re-authenticate subsequent requests in the
same session (which may span multiple TCP/HTTP sessions).

If the session ID is being used as a proxy for authentication, I would
prefer to do the job right.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 20 Jul 2012 21:38:38 +0200

> provided to support those cases, developers have largely just hacked it in.

Exactly.

> without risk of inappropriate disclosure of sensitive information.

Indeed, and that's what's being done with cookies nowadays, except it
requires that LBs decipher TLS only to get this cookie ! That's why there
have been some thoughts about reusing the IPv6 flow label for this [1] [2].

> The one

This example is often given but we regularly need to show that it does not
really exist in practice. Even if you made it unpredictable or whatever,
it's trivial for a client to always stick to the same token once obtained.
Cookies already suffer from this and this is not what is exploited for DDoS
attacks, what is targetted is weaknesses in the parsers (eg: slowloris),
and huge amounts of more or less valid requests to try to overwhelm the
first point (hence the LB). Attackers have no business wasting their time
enumerating server identifiers to try the domino effect on them, the domino
effect happens by itself if they're overloaded anyway.

> define the mechanism within HTTP/2.0.

I tend to agree with a grain of salt. There are some places where you
find content delivery servers behind the LB and a small farm of login
servers. The LB then relies on the presence (or even freshness) of the
application session cookie to decide what farm to send the request to.
It's not critical because anyway such an architecture needs provisions
for letting the content server redirect to the login farm when it does
not know the session. That said, we're possibly at the frontier between
what is pure routing at low cost and what is L7 processing which will
always exist anyway with its associated costs.

> Reasonable?

Seems reasonable to me at least.

Willy

[1] http://tools.ietf.org/html/draft-carpenter-flow-label-balancing-01
[2] http://tools.ietf.org/html/draft-tarreau-extend-flow-label-balancing-00

---

From: James M Snell <[email-masked]>
Date: Fri, 20 Jul 2012 12:51:26 -0700

On Fri, Jul 20, 2012 at 12:36 PM, Phillip Hallam-Baker <[email-masked]>wrote:

> [snip]

That's precisely it... at least when we're talking about session ID's at
the application level. Perhaps this is just a matter of (a) defining a
protocol-level routing token mechanism and (b) defining a reasonable
stateful-authentication scheme and leverage both to encourage developers
away from the abuse of cookies for both of these uses.

- James

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Jul 2012 15:59:38 -0400

Perhaps what we could do is to define a TLS extension that could carry
a session ID (possibly even a session authenticator) enclair. This
would:

1) Decrease disincentives to use TLS (i.e. difficulties using it with
load balancers)

2) Provide an incentive to upgrade to support the new session ID scheme.

Given that TLS is regularly supported through a front end box type
approach, it would of course be necessary to still carry the session
id as a HTTP header in addition.

-- 
Website: http://hallambaker.com/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 20 Jul 2012 20:16:04 +0000

In message <[email-masked]>
, James M Snell writes:

>originating from the same client.

And here it might get tricky:  What do we mean by "client", if every
public PC in the library has been routed through the same HTTP-filter ?

I suspect we actually mean "user" and not "client".

(This is btw. where my "anon/identified-user" bit idea comes from)

>This token is NOT intended to be used to
>all.

Well, if the client-end is entirely in charge of producing the
session-id, it is in essence just a random number, and there are
only so many bad things you can do with a random number, so if the
application can beneficially use it (to look up server-side state ?)
then it should be exposed.

The "anon/idendtified" bit should always be exposed if we do that.

>The token could, theoretically, be transmitted entirely in the clear
>of the token.

It is at this point, not clear to me if the token would be hop-by-hop
or end-to-end.  There are significant advantages to both, hop-to-hop
in particular if the "chain" gets broken by HTTP/1.1 hops underway,
but "end-to-end in HTTP/2.0 protocol" solves that too.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 20 Jul 2012 20:34:13 +0000

In message <[email-masked]>
, Phillip Hallam-Baker writes:

>side [...]

What I'd like to see, as the end result, is that by default my
browsers will invent a new anonymous session-id for every site I
go to.

On sites I want to come back to, or want to customize my view or
whatever, I check a checkbox on my browsers saying "keep session",
which will make the browser always reuse the same session-id for
that site.

Obviously, my different browsers will use different sesion-ids for
the same site, they are random by nature, but if I want it, they
will get stable session-id's from all my browsers, and can
tie those session-ids to whatever "account" they have on me.

If they are smart enough to move the customization settings back
to the server, instead of dumping them in cookies in my browser,
they will then be able to offer me a consistent view across
all my browsers.

Should I one day log into the site from an anonymous PC at
the library, I will have to authenticate before the site
recognizes me.

The library's PC will always send anonymous session-ID's, (the
checkbox should be removed on shared browsers by the sysadmin) and
the server will know not to associate them with my account.

The server can still uses the server-side settings to offer me my
usual view of the site, but now without polluting the librarys
browser with cookies, that will make the next user who goes
to the same site look like me.

For a lot of the "Hello Samuel B. Kennedy" sort of customized
web-pages, this would be all they ever need, and will work
better for them than cookies ever did.

And these session-ids are _not_ authenticators, the are merely
identifiers.  The site should use whatever authentication it
deems necessary for the traffic it offers.