Re: [websec] draft-williams-websec-session-continue-prob-00

Yoav Nir <> Tue, 15 January 2013 14:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1001621F87D9 for <>; Tue, 15 Jan 2013 06:04:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.765
X-Spam-Status: No, score=-9.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_FWDLOOK=1.666]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CCLqtMtAc5H9 for <>; Tue, 15 Jan 2013 06:04:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9143121F873E for <>; Tue, 15 Jan 2013 06:04:23 -0800 (PST)
Received: from ([]) by (8.13.8/8.13.8) with ESMTP id r0FE4KJL015428; Tue, 15 Jan 2013 16:04:20 +0200
X-CheckPoint: {50F55F6D-3-1B221DC2-2FFFF}
Received: from ([]) by ([fe80::80df:1c2c:3d29:3748%11]) with mapi id 14.02.0328.009; Tue, 15 Jan 2013 16:04:20 +0200
From: Yoav Nir <>
To: James M Snell <>
Thread-Topic: [websec] draft-williams-websec-session-continue-prob-00
Thread-Index: AQHN8p9I7Of/xGWYU0m2QufJ2qbPJ5hKS6iA
Date: Tue, 15 Jan 2013 14:04:19 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4613980CFC78314ABFD7F85CC302772111984CB4ILEX10adcheckpo_"
MIME-Version: 1.0
Cc: "<>" <>
Subject: Re: [websec] draft-williams-websec-session-continue-prob-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Jan 2013 14:04:25 -0000

Hi James

I've now read your draft. It looks to solve the same kind of problem as PHB's integrity draft [1], although that one currently uses HTTP/1 syntax.

The protocol you propose binds a key to a session (or "KEY-ID") and this allows to integrity protect both requests and responses. It also allows the client to bind specific requests to specific sessions, which is one of the requirements in the session-continue draft. Integrity protection of the requests (an possibly responses) is definitely a key component of any solution to make sessions secure. It doesn't help to authenticate just the fact that there is a request, if we then allow a proxy to rewrite the entire content of the request.

What's missing for me is a binding of that key-id to an authenticated identity. Identities can be authenticated multiple ways. There's the user certificate in TLS, Some better or worse HTTP schemes (everything from Basic to ZKPPs), two-factor methods using some side-channel (such as instant messaging to mobile phones), and even HTTP forms, whether they are the insecure kind we use today or something with browser-based encryption. I think it would be a worthy goal to have all of these bind somehow to the key-id.

The other thing that's missing, but should probably be in a separate document (that I think we're not ready to start yet) is a specification of client behavior, meaning when should the client use the same session id (or "key id") for different requests. For example, if I have gmail open in one browser tab, and in another tab I have a site, where teh HTML says "<img src="<>">", should the request to<> use the same key id that I am using with GMail?  The one that is bound to my identity? With the current cookie mechanism, the answer is yes. If we define a new session mechanism, we can re-think this.


On Jan 14, 2013, at 11:36 PM, James M Snell <<>> wrote:


Just jumped over here from the http list per Yoav Nir's request for feedback with regards to the draft-williams-websec-session-continue-prob draft.

Overall I think the draft is a good start. There definitely does need to be more of an explanation as to why the existing cookie-based mechanism is bad.

As far as more forward looking feedback is concerned, I wanted to point to the In-Session Key Negotiation draft I wrote as input to the ongoing http/2 discussion

This draft introduces a new (currently experimental) bidirectional key-negotiation sub-protocol within spdy/http2 for the negotiation of secure keys and can be used for the establishment of authenticated and unauthenticated sessions. (Note that I'm just making sure folks know about this draft as it is relevant to the discussion)... Running down through the list of requirements stated by the websec-session-continue-prob draft it covers a good deal of the issues.

- James