Subject: [http-state] the "state" in http-state

From: Thomas Fossati <[email-masked]>
Date: Thu, 9 Jun 2011 13:13:25 +0200

Folks,

http-state wg is dead, still there's a lot of discussion burning under his ashes.  Indeed, lots of people seem to have strong interest (and opionions) about state/session handling in the context of HTTP based applications.

I think, and probably most of you agree, that IETF should provide mechanisms for full and secure (with regards to a serious threat model) state management facilities for HTTP apps.

That said, should we push real -- as opposed to soft and insecure as in cookie-based solutions -- state management into HTTP ?  I.e. should we consider enhancing HTTP with facilities to turn it into a (optionally) stateful beast ?  

Or should we pass the mic to other layers ?

I think this is the fundamental question that we must answer clearly before evaluating/discussing the different -- loosely related -- tech proposals that are now surfacing.

t.

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 9 Jun 2011 13:42:16 -0400

Thomas,

My personal opinion is that we need something that integrates well with HTTP
*if* there is agreement that we need something that works outside of TLS.
The fact is that lots of applications maintain some state, if for no other
reason than to associate a request with a particular user (or user agent).

Question is, should we just say that TLS is must be used and not use
non-secure connections when state management is necessary?  I've seen TLS
significantly degrade the performance of servers, though I just saw a
posting this week suggesting TLS does not degrade server performance.

TLS performance issues have been my primary concern.  Are they founded or
not?

Are the reasons for integrating state management functionality in HTTP aside
from TLS performance concerns?

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Thomas Fossati
> Sent: Thursday, June 09, 2011 7:13 AM
> To: IETF HTTP State WG
> Subject: [http-state] the "state" in http-state
> 
> Folks,
> 
> http-state wg is dead, still there's a lot of discussion burning under
> his ashes.  Indeed, lots of people seem to have strong interest (and
> opionions) about state/session handling in the context of HTTP based
> applications.
> 
> I think, and probably most of you agree, that IETF should provide
> mechanisms for full and secure (with regards to a serious threat model)
> state management facilities for HTTP apps.
> 
> That said, should we push real -- as opposed to soft and insecure as in
> cookie-based solutions -- state management into HTTP ?  I.e. should we
> consider enhancing HTTP with facilities to turn it into a (optionally)
> stateful beast ?
> 
> I think this is the fundamental question that we must answer clearly
> before evaluating/discussing the different -- loosely related -- tech
> proposals that are now surfacing.
> 
> t.
> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 10 Jun 2011 00:33:28 +0200

> *if* there is agreement that we need something that works outside of TLS.

Exactly.

> posting this week suggesting TLS does not degrade server performance.

Basically, it depends on how it is used: certificate key sizing, ciphersuites, number of intermediate certs up to the root, OCSP response caching, etc. all of these can tell apart a nearly no-overhead TLS from a huge burden placed over the HTTP transaction.

I don't know if any such document already exist, but in this respect we could provide some guidelines for TLS trimming in order to provide reasonably good performance with HTTP.  
It'd be a useful resource for both web application deployers and browser implementers.

> from TLS performance concerns?

Basically, some times ago my concern was the mere existence of a TLS stack fitting constrained/embedded contexts.
CyaSSL radically changed my perspective.

t.