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

Adam Barth <ietf@adambarth.com> Fri, 29 January 2010 07:17 UTC

Return-Path: <adam@adambarth.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D34673A6942 for <http-state@core3.amsl.com>; Thu, 28 Jan 2010 23:17:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.67
X-Spam-Level:
X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rJHq+8eHZxY for <http-state@core3.amsl.com>; Thu, 28 Jan 2010 23:17:09 -0800 (PST)
Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by core3.amsl.com (Postfix) with ESMTP id 9730C3A6912 for <http-state@ietf.org>; Thu, 28 Jan 2010 23:17:09 -0800 (PST)
Received: by pzk5 with SMTP id 5so1505457pzk.29 for <http-state@ietf.org>; Thu, 28 Jan 2010 23:17:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.7.16 with SMTP id 16mr344399wfg.117.1264749448139; Thu, 28 Jan 2010 23:17:28 -0800 (PST)
In-Reply-To: <6AE67277-5B09-4784-ABC9-0B9228201DDE@gbiv.com>
References: <7789133a1001220050m56cc438x35099b7972639331@mail.gmail.com> <alpine.DEB.2.00.1001220957240.9467@tvnag.unkk.fr> <33259CFA-E50A-46D7-A315-5D68ACB69CDB@apple.com> <2C56E4FA-8BE2-479A-AA53-E64DC3A907E2@gbiv.com> <7789133a1001281353k3498690dq7d60d52a19eb1e7e@mail.gmail.com> <6AE67277-5B09-4784-ABC9-0B9228201DDE@gbiv.com>
From: Adam Barth <ietf@adambarth.com>
Date: Thu, 28 Jan 2010 23:17:08 -0800
Message-ID: <7789133a1001282317i41502ce7pe423b2e7a9a034ed@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Daniel Stenberg <daniel@haxx.se>, http-state <http-state@ietf.org>
Subject: Re: [http-state] Ticket 6: host-only cookies
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2010 07:17:11 -0000

Roy,

I'm sorry for making the discussion personal instead of technical.
I'll keep to the technical merits in the future.  If you see me
stepping over the line again, please don't hesitate to call me on it.

Thanks,
Adam


On Thu, Jan 28, 2010 at 2:12 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> On Jan 28, 2010, at 1:53 PM, Adam Barth wrote:
>> On Thu, Jan 28, 2010 at 1:47 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>>> 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.
>>
>> I agree with your conclusion but I disagree with your tone.  I'm not
>> sure yours is the final word on what the spec will or will not define.
>> Your tone is arrogant and disrespectful.
>
> 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.
>
> This is the last comment I will respond to you regarding tone.
> You are not my mother and you are not my chair.  You will either
> stop playing these junior psychology games learned from HTML5
> or I will ask the chairs to remove you as draft editor.
>
> ....Roy
>
>