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

Barry Leiba <> Wed, 24 October 2012 05:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0A9A21F8CC2 for <>; Tue, 23 Oct 2012 22:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.107
X-Spam-Status: No, score=-103.107 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f3DYxICVXlDB for <>; Tue, 23 Oct 2012 22:47:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DF5AC21F8CE3 for <>; Tue, 23 Oct 2012 22:47:09 -0700 (PDT)
Received: by with SMTP id k13so928200lbo.31 for <>; Tue, 23 Oct 2012 22:47:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=t13488eeeN7yEAdSGnGH/1jtLdHaTejCZUHhJFIx8PI=; b=zxeDX/yNw3iLdHuYSkrCsceDC4EDqJJMJipLWDjOA3/4W/iIQmBng9bRQY7wYKizXl ASN/tmxc6MhHAbsOWPRA19PVmQLv9ujFogVR/0ibCa28vi20o55Uph9OxhtisIV+PMO8 0XGSrpEhXqxhvJEdOaS5eiAY4TGtYKxHHBdgmx8pQK3xabE/E75XL3T/C5LR+DRsqms5 X/CKG4rB0zPHmhAgIHCydtBS9L2kO75tb3KE4yg6+3msnXn4PX4SCEid+5ZJ7aWnpF0x w7ZPqqmHE8UY1oNlHUpNCFurFyzeyi1mY8jyGxkZzkFe8+8Q0vusOazc9Q7ktknuuSVJ 3O3A==
MIME-Version: 1.0
Received: by with SMTP id jf4mr13491756lab.47.1351057628845; Tue, 23 Oct 2012 22:47:08 -0700 (PDT)
Received: by with HTTP; Tue, 23 Oct 2012 22:47:08 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 24 Oct 2012 01:47:08 -0400
X-Google-Sender-Auth: G-KvPl2e8UP_dgRQe1LBs2P7jl0
Message-ID: <>
From: Barry Leiba <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Mark Nottingham <>
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: Wed, 24 Oct 2012 05:47:10 -0000

MNot says...
> 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.

I don't see any extension there.  I see it using the cookie mechanism
defined in 6265, and specifying how to use encrypted cookies instead
of plain-text ones.

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

I have sympathy for that idea, but it doesn't bear out:

The authors proposed it to the httpstate WG on 22 Feb 2011:

They followed up on 25 Feb and 7 March:

On 13 March they tried to get on the agenda for the Prague IETF meeting:

That didn't happen, and the working group was closed in May 2011,
after the publication of RFC 6265:

The only responses to any of their messages were two from Adam Barth
in the first (22 Feb) thread.  There appears to have been no interest
in taking on the work in httpstate.

What that says to me is that httpstate had the chance to take it, and
opted out.  It's not valid to now say that they should have, and this
document conflicts.

All that said, here's what I think, as the AD who's shepherding this
through the conflict review:

1. It's probably acceptable to do this through the ISE -- that is,
this probably does not *conflict* with IETF work.

2. It's probably better to do this through the IETF Stream -- it will
get better review and be a more solid document that way.

3. The authors are happy to do it that way; I've talked with them about it.

4. We could charter a new "son of httpstate" working group for this,
we could fit it into an existing working group (httpbis or appsawg,
likely), or we could do it as an AD-sponsored document (I would be
happy to sponsor it, and I suspect Stephen would also).  If we did
that, it would go as Proposed Standard   ... or we could let it
continue through the Independent Stream, as Informational.