Re: Introducing a Session header...

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 <grmocg@gmail.com> 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.
>
> In the event we allow cleartext communications (not debating that here),
> security for the nonce/session-id is an issue.
>
> -=R
>
>
>
> On Fri, Jul 20, 2012 at 9:56 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:
>
>> In message <CAP+FsNcWPw6j68Y9g9HfAWxZu-83W4p1cX0OTd4Fngky=
>> PdvgA@mail.gmail.com>
>> , Roberto Peon writes:
>>
>> >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.
>>
>> 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.
>>
>>
>> --
>> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>> phk@FreeBSD.ORG         | TCP/IP since RFC 956
>> FreeBSD committer       | BSD since 4.3-tahoe
>> Never attribute to malice what can adequately be explained by
>> incompetence.
>>
>
>