Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol

Mark Nottingham <> Mon, 22 October 2012 22:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 774E211E80E0 for <>; Mon, 22 Oct 2012 15:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.044
X-Spam-Status: No, score=-104.044 tagged_above=-999 required=5 tests=[AWL=-1.445, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eD2Bz+no6CIz for <>; Mon, 22 Oct 2012 15:31:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A149C11E80E7 for <>; Mon, 22 Oct 2012 15:31:38 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4A96122DD6D for <>; Mon, 22 Oct 2012 18:31:31 -0400 (EDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Tue, 23 Oct 2012 09:31:30 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
X-Mailer: Apple Mail (2.1499)
X-Mailman-Approved-At: Tue, 23 Oct 2012 14:09:57 -0700
Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Oct 2012 22:31:39 -0000

As far as I can tell, this document specifies some extensions to the Cookie / Set-Cookie (RFC6265), and/or "squats" on some pre-defined cookie names. It's hard to tell, both because of how the draft is written, and because I read it very quickly.

6265 doesn't define how it's to be extended very well (possibly because the underlying assumption is that extensions are VERY difficult to deploy). However, the precedent of an independent stream RFC defining such extensions, or worse "squatting" on the cookie name space (which is very widely used and thus very difficult to guarantee an absence of conflict) is concerning.

It seems to me that this *might* therefore conflict with the (previous) HTTPSTATE WG's work. 


On 18/10/2012, at 1:25 PM, Barry Leiba <> wrote:

> A document titled "Secure Cookie Sessions for HTTP" has been submitted
> to the Independent Stream Editor (ISE):
> The IESG has been asked to review the document, as specified in RFC
> 5742, Section 3.  The Security and Applications Area Directors are
> looking for input for that review.  Please post any relevant comments
> to the Security Area list, <>rg>, as soon as possible, and at
> least by 1 November 2012.
> Note: Please do NOT post responses to any of these mailing lists.
> Respond only to <> (using the subject line of this
> message).
> Please read RFC 5742, Section 3, and be aware that we are not looking
> for detailed comments on the document itself (see below).  We
> specifically need input on whether this document is in conflict with
> work that's being done in the IETF.  Look at the five possible
> responses specified in that section, and help us determine whether any
> of 2 through 5 applies.  Please be specific in your response.
> In addition to this, we're sure that the authors and the ISE would
> appreciate comments about the document.  If you have those, you may
> send them directly to the authors at
> <>
> and to the ISE at <>rg>.
> General discussion of the document on these lists or the saag list will
> likely not get to the authors or the ISE.
> Barry Leiba, Applications AD

Mark Nottingham