IETF Logo Mail Archive

Re: [http-state] IETF-wide Last Call for -httpstate-cookie-10 ?

"Shelby Moore" <shelby@coolpage.com> Thu, 26 August 2010 23:27 UTC

Return-Path: <shelby@coolpage.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 80E3F3A684D for <http-state@core3.amsl.com>; Thu, 26 Aug 2010 16:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.338
X-Spam-Level:
X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599]
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 oS4Y0HlgfMOQ for <http-state@core3.amsl.com>; Thu, 26 Aug 2010 16:27:08 -0700 (PDT)
Received: from www5.webmail.pair.com (www5.webmail.pair.com [66.39.3.83]) by core3.amsl.com (Postfix) with SMTP id 439593A67F7 for <http-state@ietf.org>; Thu, 26 Aug 2010 16:27:08 -0700 (PDT)
Received: (qmail 31128 invoked by uid 65534); 26 Aug 2010 23:27:40 -0000
Received: from 121.97.54.174 ([121.97.54.174]) (SquirrelMail authenticated user shelby@coolpage.com) by sm.webmail.pair.com with HTTP; Thu, 26 Aug 2010 19:27:40 -0400
Message-ID: <12647ee5c22f64943faffb7db38a53ad.squirrel@sm.webmail.pair.com>
In-Reply-To: <alpine.DEB.2.00.1008262239160.31575@tvnag.unkk.fr>
References: <4cefb87bd1a796e242c1218b50629f1c.squirrel@sm.webmail.pair.com> <alpine.DEB.2.00.1008262239160.31575@tvnag.unkk.fr>
Date: Thu, 26 Aug 2010 19:27:40 -0400
From: Shelby Moore <shelby@coolpage.com>
To: Daniel Stenberg <daniel@haxx.se>
User-Agent: SquirrelMail/1.4.20
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: HTTP-state mailing list <http-state@ietf.org>
Subject: Re: [http-state] IETF-wide Last Call for -httpstate-cookie-10 ?
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: shelby@coolpage.com
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: Thu, 26 Aug 2010 23:27:09 -0000

Daniel I agree with everything you wrote, except one quibble below, and I
appreciated your reply very much.

>>> You're apparently referring to 2nd para of sec 6.2. I'm personally fine
>>> with the wording and sentiment of the statements there. again WG would
>>> have
>>> to consider any changes.
>>
>> Above you wrote that you are only documenting the way the web is now.
>> Now
>> you are saying it is ok to insist that browsers replace the set-cookie
>> function with one that will not work with existing websites.
>
> I agree with the current wording of the draft because I think the way
> cookies
> have currently been handled by APIs etc is a major contributors to the
> mess
> and problems we have with cookies today.
>
> But I don't think the exact wording of that section is terribly important
> as
> it is just a suggestion that again doesn't have any specific meaning for
> the
> actual protocol.


Unfortunately, I fear it does aim to kill the general string form of
set-cookie, and I disagree that Almost Better Than Nothing is security.

The problem with bad programming won't go away by removing functionalty.

Fix the other security holes so that users can start to home in on those
bad sites and kill them in the market.  As it is now, there are so many
real security holes that users can't differentiate bad programming from
good programming.

Please don't kill programming, while trying to fix security.  Go after the
real holes, not the Almost Better Than Nothing non-security.

Protocols should say what they mean.  They are very specific documents. 
We don't want to create confusion.  Either say, "deprecate set-cookie for
strings" or change it as I suggested.

Thank you.

v2.23.0 | Report a Bug | By Email