Re: [http-state] Ticket 6: host-only cookies

Eran Hammer-Lahav <> Fri, 29 January 2010 07:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AE223A697F for <>; Thu, 28 Jan 2010 23:47:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ChpIG05Qpdaw for <>; Thu, 28 Jan 2010 23:47:04 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 361273A6970 for <>; Thu, 28 Jan 2010 23:47:02 -0800 (PST)
Received: (qmail 8149 invoked from network); 29 Jan 2010 07:47:23 -0000
Received: from unknown (HELO ( by with SMTP; 29 Jan 2010 07:47:23 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([]) with mapi; Fri, 29 Jan 2010 00:47:25 -0700
From: Eran Hammer-Lahav <>
To: http-state <>
Date: Fri, 29 Jan 2010 00:47:17 -0700
Thread-Topic: [http-state] Ticket 6: host-only cookies
Thread-Index: AcqgtA46qjivrhx6QSOQniUuhLAQhwAAEBlg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437899D25C4@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [http-state] Ticket 6: host-only cookies
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Jan 2010 07:47:05 -0000


It is far too easy to lose sight of the issues and get bogged down in personal commentary. We've got plenty of technical challenges to sort through and I'd like to keep this effort on topic.

Roy's comments correctly reflect IETF process and guidelines. However, there are no absolutes and the guiding principal is always reaching rough consensus. That means we don't count votes and need to address each and every concern or objection raised. It is also common for an IETF proposed standard to document existing practice even when it is insecure or non-compliant, as long as it is explicitly called out and noted clearly.

Jeff and I are here to help with the process and to make sure we successfully fulfill our charter in a manner that is consistent with IETF process.


> -----Original Message-----
> From: [] On
> Behalf Of Bil Corry
> Sent: Thursday, January 28, 2010 11:24 PM
> To: Roy T. Fielding
> Cc: Daniel Stenberg; http-state
> Subject: Re: [http-state] Ticket 6: host-only cookies
> Roy T. Fielding wrote on 1/28/2010 1:47 PM:
> > On Jan 23, 2010, at 8:36 PM, Maciej Stachowiak wrote:
> >> On Jan 22, 2010, at 3:00 AM, Daniel Stenberg wrote:
> >>
> >>> On Fri, 22 Jan 2010, Adam Barth wrote:
> >>>
> >>>> 1) Specify host-only cookies to match Firefox, Chrome, Safari, and
> >>>> Opera. This is best for security, and I think there's a good chance
> >>>> that IE will adopt host-only cookies in future, but I don't have
> >>>> any citable evidence for this belief.  (The draft currently matches
> >>>> this proposal.)
> >>> Even though this would be the best security option (and in general I
> think it makes more sense), I don't think we can neglect that one rather
> widely used implementation doesn't do it this way.
> >>>
> >>> Sites out there that depend on this bug/feature in IE will break. And we
> know there exist many IE-crafted sites out there (although I guess nobody
> really knows how many of those that might depend on this particular thing).
> >>>
> >>> I'm guessing this is a difference that simply will remain for a good while
> forward. The non-IE browsers won't do it this way due to security and IE does
> it this way by tradition and the good old "we won't change any behaviors
> since then something will break for our users".
> >>>
> >>> So, I'm afraid I'm leaning towards (3): Allow both behaviors.
> >> If Microsoft is unwilling to change their behavior, then I'd like to hear it
> from them rather than guessing. Are there any Microsoft reps in this group?
> Can we get any to join?
> >>
> >> I would strongly prefer a single behavior unless we get a clear statement
> from Microsoft that they absolutely will not change.
> >
> > On security issues, there is no Microsoft exception.  The spec will
> > define the more secure alternative and the vendors will adjust their
> > behavior long before we are done.  Servers are fully-capable of
> > adjusting their behavior for previously deployed user agents' bugs
> > without further assistance from the standard.
> and:
> Roy T. Fielding wrote on 1/28/2010 2:12 PM:
> > This is an IETF spec, so it will obey IETF norms, and I can tell you
> > that it won't pass IESG review with a non-secure alternative being
> > allowed as part of the proposed standard.  My tone is from experience
> > in writing standards and experience in writing servers.
> The spec we produce may not pass IESG review anyway given we're
> specifying behavior that violates RFC 2109 (and presumably httpbis).  The
> purpose of this WG is to create a spec that reflects how cookies are actually
> implemented in real life across common UAs and servers, including the
> insecure and inconsistent behavior.  Your position that 'vendors will adjust
> their behavior' has not borne out as RFC 2965 illustrates (and the very reason
> for this WG).
> We will produce a 'real-life' cookie spec.  It will be useful to implementors
> seeking to make their products as broadly compatible as possible and is long
> overdue.  It's up to the IETF if they want to accept it, but that doesn't change
> our purpose and charter, nor does it reduce the need for our document and
> the value it will bring to the internet community at large.
> Going back to the issue at hand, if Microsoft is unwilling to adopt the more
> secure behavior, then our charter states we must "seek consensus to reduce
> variation by selecting among the most widely used variations."  Note that it
> doesn't say we must eliminate variation, only reduce it.  And it's consensus-
> based.  Your vote for option 1 has been noted.
> - Bil
> _______________________________________________
> http-state mailing list