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

Willy Tarreau <> Thu, 18 October 2012 17:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 422D721F8530 for <>; Thu, 18 Oct 2012 10:41:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.774
X-Spam-Status: No, score=-4.774 tagged_above=-999 required=5 tests=[AWL=-2.731, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PkBRQxGXAw05 for <>; Thu, 18 Oct 2012 10:41:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4CCA321F8507 for <>; Thu, 18 Oct 2012 10:41:22 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q9IHfDlZ012063; Thu, 18 Oct 2012 19:41:13 +0200
Date: Thu, 18 Oct 2012 19:41:13 +0200
From: Willy Tarreau <>
To: Barry Leiba <>
Message-ID: <>
References: <> <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/
X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -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: Thu, 18 Oct 2012 17:41:23 -0000

On Thu, Oct 18, 2012 at 01:22:38PM -0400, Barry Leiba wrote:
> > Well, maybe it's a matter of point of view. Adam took great care to
> > rework the cookie spec and achieve RFC6265 with a number of usage
> > recommendations to use cookies in the safest way. Since this draft
> > suggests a usage which seems totally insecure to me, I found it
> > appropriate to raise it as conflicting with the intended use of
> > cookies. Maybe I was wrong, and if so please accept my apologises.
> > Then it's unclear to me what kind of conflict should be raised :-/
> True, and it's sometimes unclear to us as well.

OK that makes me feel more comfortable now :-)

> I'll see your :-/ and raise you a :-(
> What we're looking for is this sort of thing:
> - Is this document in direct conflict with current work in a working
> group?  Which one(s)?
> - Should this be handled by an existing working group?  Which one?
> - Should a new working group be chartered for this, rather than doing
> it as an Independent Submission?
> - Does it appear that the authors are trying to get around the system
> by submitting this to the ISE?
> - Is this spec proposing something sufficiently harmful that it needs
> proper IETF review to fix it?
> I suppose your comments could be arguing for that last one.

Yes, seems appropriate.

> But look at the list in RFC 5742, Section 3, and comment here on which
> of the five responses you think applies to this document.

I'm balanced between 3 and 5 :
  3. The IESG has concluded that publication could potentially disrupt
     the IETF work done in WG <X> and recommends not publishing the
     document at this time.

  5. The IESG has concluded that this document extends an IETF protocol
     in a way that requires IETF review and should therefore not be
     published without IETF review and IESG approval.

Basically if used as general purpose cookies, the impossibility to ensure
non-replay would be a no-go for me as it goes against the principles of
RFC6265, hence #3.

However, if designed for use in very specific cases I'm not aware of, then
probably the document needs some editorial adjustments to clearly indicate
that it is not for general use and possibly be reviewed by specialists to
ensure nothing was left unchecked, hence #5.

> And then
> definitely give your other feedback on the document to the ISE and the
> document authors.


> Thanks, Willy.

You're welcome.