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

"Paul E. Jones" <paulej@packetizer.com> Thu, 09 June 2011 17:42 UTC

Return-Path: <paulej@packetizer.com>
X-Original-To: http-state@ietfa.amsl.com
Delivered-To: http-state@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF22D11E819A for <http-state@ietfa.amsl.com>; Thu, 9 Jun 2011 10:42:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3o-BcCZzB71 for <http-state@ietfa.amsl.com>; Thu, 9 Jun 2011 10:42:32 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id F188D11E8130 for <http-state@ietf.org>; Thu, 9 Jun 2011 10:42:31 -0700 (PDT)
Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p59HgOmP028826 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jun 2011 13:42:30 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1307641350; bh=byrtIqY1wWYewpYPJJGclM99KBhWa0paebnUtxglTIk=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=NDMcp+opG+brasVynX5/sJFryd9HPrASdOMN9k1p7ft42P6E2rpvHDttQnYY12qH6 vFLiL8zeTEi2gbPSRoY5og92J7QBoM8taMMSggbh5UjTyhjd+hb1EOvE1UzrgPffl6 iVRmWVcY/Fy2oITaSkbdMWDUkHxC2bbwPWyW/07E=
From: "Paul E. Jones" <paulej@packetizer.com>
To: 'Thomas Fossati' <tho@koanlogic.com>, 'IETF HTTP State WG' <http-state@ietf.org>
References: <18AD8547-9778-47DB-8D16-AEB9477F6640@koanlogic.com>
In-Reply-To: <18AD8547-9778-47DB-8D16-AEB9477F6640@koanlogic.com>
Date: Thu, 09 Jun 2011 13:42:16 -0400
Message-ID: <03b101cc26cc$9635bdb0$c2a13910$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIaLT1ilkCRT9amwYZe+S5gD9w2YpQZECIQ
Content-Language: en-us
Subject: Re: [http-state] the "state" in http-state
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jun 2011 17:42:33 -0000

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: http-state-bounces@ietf.org [mailto:http-state-bounces@ietf.org]
> 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 ?
> 
> 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.
> _______________________________________________
> http-state mailing list
> http-state@ietf.org
> https://www.ietf.org/mailman/listinfo/http-state