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

Stephen Farrell <> Wed, 24 October 2012 14:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32F6721F8ACA for <>; Wed, 24 Oct 2012 07:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.799
X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MbfeG9h5Fbyd for <>; Wed, 24 Oct 2012 07:31:58 -0700 (PDT)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id 4170A21F8A89 for <>; Wed, 24 Oct 2012 07:31:53 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 69DE6171479; Wed, 24 Oct 2012 15:31:52 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1351089111; bh=wSxtzj8tPB5/+n yZMX4fZPyuwvDXIzu5HSyyjsktUw0=; b=XtZOu9McfOkzkAiLLqY04qcy0Pm3PQ QwilSbYdxdGguWSkAgsq3oJHz+Dx0XQi798t4YFinCae80p7TP76JKFyDHjonCim E8kHKNoJc1LzVXgFebteRxkIH43Jf1QNNdXybRhyhC50+6a4pmQ/Qj2LMJ1LBtCq JihG2oPsB9gweBeKtN2IvSyuhb+9hQkGdfm3CwWnD4sTtsdgmGjfpGHRFaBd0zX8 9PBw3aXyUiRO7S5dDMj42NywQ+ytRd/cfzamiaPeNtt1xQTWUHBDEx/YD9Ps84LS mnrAtYFx/fmzWCTOuXyQAeT8HMXfo61glRV+24iI9rGInVPWPGChTO4A==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id jPaMarzU2D8A; Wed, 24 Oct 2012 15:31:51 +0100 (IST)
Received: from [IPv6:2001:770:10:203:93a:7c18:9b35:51a7] (unknown [IPv6:2001:770:10:203:93a:7c18:9b35:51a7]) by (Postfix) with ESMTPSA id 30A37171478; Wed, 24 Oct 2012 15:31:47 +0100 (IST)
Message-ID: <>
Date: Wed, 24 Oct 2012 15:31:47 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1
MIME-Version: 1.0
To: Barry Leiba <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 14:31:59 -0000


On 10/24/2012 06:47 AM, Barry Leiba wrote:
> 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.

Adding the company name to the title would still be good
here if we take this route I think. (If for no other reason,
to avoid confusion in case we do want a standard flavour of
this later.)

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

I do think a standard for this could be useful, lots of
sites do emit encrypted/integrity-protected cookies and
probably lots of 'em roll their own badly.

It'd be good to try get a feel for whether a standard would
be likely to be adopted though before going down this route
I think. Not sure how best to get that done though as I guess
it'd more be one for implementers of application frameworks
and toolkits, who probably don't read saag. That might
take a while though.

So, overall, I'd say maybe best might be to stick to
the ISE route for this, to get it done (assuming that's
what the authors would prefer) but then also try figure
out if there's a useful standard to be written here,
which might well start out from this document, or
maybe we'd find out that there're already slightly
different ways to do this that are closer to current
implementations that'd be more likely to get deployed.

For example load balancing might call for slightly
more complex key mgmt, or maybe there'd be a reason
to also encrypt or to omit the ATIME field. I've no
idea if that's the case, but we'd want to figure it
out for a standards track document, and that might
take enough time that the authors would really prefer
to take the ISE route for now.