Re: [http-state] [Technical Errata Reported] RFC6265 (3663)

Barry Leiba <barryleiba@computer.org> Wed, 07 August 2013 19:04 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: http-state@ietfa.amsl.com
Delivered-To: http-state@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8A821F9A70 for <http-state@ietfa.amsl.com>; Wed, 7 Aug 2013 12:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.976
X-Spam-Level:
X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkVIZ647fAOR for <http-state@ietfa.amsl.com>; Wed, 7 Aug 2013 12:04:07 -0700 (PDT)
Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id E699E21F9406 for <http-state@ietf.org>; Wed, 7 Aug 2013 12:04:06 -0700 (PDT)
Received: by mail-qe0-f53.google.com with SMTP id f6so1207896qej.26 for <http-state@ietf.org>; Wed, 07 Aug 2013 12:04:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=mPj7VIyBw9lveanaxVNueAhnqgP4zGNxlO+KrXuE32E=; b=o7YKWtCQ9B4U3RIvBwMERIpU4ys5ACVzcZGjz08N2GNu0v3OZP6WOWOTRRCUOfliZe 0ubGBixOn25oqDk5gn5gyOKLX77s/RvEUocY0y58Jfn1Ti1t/wAX/idC5Dm0dKd7xLYu okZ39YB64tMkZ2fNQkr2eZX45FpjTkKCi4L1gJw0hlEFAov3Z2blvblz9Vj9yZTIKMeK I7/CNr6SbPsNez6d/U+ldS1gaIrO19GPea7Uq09pAjK2opiuz/HgGqJF9SVC0gWsoKps LKZNodFhlkFZsFJ36WCvl1BfCxyYIy7AiF8bfPqFaHBt2wRx9xpPILDs39wRowHh6n+m SQNQ==
MIME-Version: 1.0
X-Received: by 10.49.30.73 with SMTP id q9mr2185575qeh.67.1375902246296; Wed, 07 Aug 2013 12:04:06 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.224.59.211 with HTTP; Wed, 7 Aug 2013 12:04:06 -0700 (PDT)
In-Reply-To: <9a2552b7ebe74621ae0fa7e5fbf78680@BY2PR03MB269.namprd03.prod.outlook.com>
References: <20130618002830.7DF236211A@rfc-editor.org> <7mavr8hhrqsfmcqt77181vqc3g3nl25s1d@hive.bjoern.hoehrmann.de> <9beb9558a94c434d84a0ccebfe4cc582@BY2PR03MB269.namprd03.prod.outlook.com> <CAJE5ia84biazW1-yOWwUmx94SGLL2daF2PPdWaj6+=5qCaigJg@mail.gmail.com> <CALaySJL21aYDJKAq233FkZrUqk2H7uboo5GwgfURsB7hnRgkqQ@mail.gmail.com> <2ed31aa7639a49ffb9d689795335e88c@BY2PR03MB269.namprd03.prod.outlook.com> <9a2552b7ebe74621ae0fa7e5fbf78680@BY2PR03MB269.namprd03.prod.outlook.com>
Date: Wed, 7 Aug 2013 21:04:06 +0200
X-Google-Sender-Auth: xTYQqpUiyvX2dtKnbrxeSIOV8w0
Message-ID: <CALaySJ+H3q=XCRtTGo2XXsEpk8vWd8fz8DJ5cTGXm_75=r0LHA@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Dave Thaler <dthaler@microsoft.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "presnick@qti.qualcomm.com" <presnick@qti.qualcomm.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, "http-state@ietf.org" <http-state@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [http-state] [Technical Errata Reported] RFC6265 (3663)
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 07 Aug 2013 19:04:08 -0000

Dave, have a look at the edited version before I click "HFDU", because
once I do I can't edit it any more:
http://www.rfc-editor.org/errata_search.php?rfc=6265&eid=3663

Does that work?

Barry

On Thu, Jul 11, 2013 at 12:06 AM, Dave Thaler <dthaler@microsoft.com>; wrote:
> Based on my reading of http://www.ietf.org/iesg/statement/errata-processing.html
> it seems that problems like the one I'm pointing out should still be Rejected if the
> WG had consensus at the time on what the current design is.  As far as I know, that's the
> case and hence an erratum appears to be the wrong way to track the "flaw" (or unexpected
> behavior).   So while I've written a longer summary (attached), I'm not adding it into the errata system.
>
> What I think is, however, reasonable in an errata is to point out that the current odd/inefficient
> behavior was intended by the WG, and thus the reader should expect it.  I think that would be
> a legitimate HFDU case under the argument that the current text causes confusion (it certainly
> did for the Microsoft folks that caused me to file the erratum).
>
> Suggested updated text you can edit in...
>
> ===<begin snip>===
>
> Section 5.1.4 states:
>>   A request-path path-matches a given cookie-path if at least one of
>>   the following conditions holds:
>>
>>   o  The cookie-path and the request-path are identical.
>
> The "identical" rule differs from the URI equivalence rule(s) in RFC 3986
> sections 6.2 and 2.1 (e.g., "If two URIs differ only in the case of hexadecimal
> digits used in percent-encoded octets, they are equivalent.")  The fact that
> equivalent URIs have different cookies arguably violates the principle of
> least astonishment.  To avoid significant confusion and prevent such surprise,
> this fact should be noted so that it is at least not unexpected.
>
> OLD:
>>   o  The cookie-path and the request-path are identical.
> NEW:
>>   o  The cookie-path and the request-path are identical. Note that this
>>        differs from the rules in RFC 3986 for equivalence of the path component,
>>        and hence two equivalent paths can have different cookies.
>
> ===<end snip>===
>
> If you can replace the original erratum text with the above, please do so.
> If you cannot, feel free to append the above prefixed with some statement
> to the effect that ABNF strings are case insensitive and so the statements about HEXDIG
> were incorrect, and this text is a corrected summary of the issue.
>
> -Dave
>
> -----Original Message-----
> From: Dave Thaler
> Sent: Monday, July 8, 2013 1:53 PM
> To: Barry Leiba; Adam Barth
> Cc: Bjoern Hoehrmann; RFC Errata System; presnick@qti.qualcomm.com; Jeff.Hodges@kingsmountain.com; http-state@ietf.org
> Subject: RE: [http-state] [Technical Errata Reported] RFC6265 (3663)
>
> Certainly the original issue as I phrased it is incorrect, so in that sense it's Rejected.
> However, there is a functionality issue as I noted that results in unexpected behavior because two RFCs have differing definitions of equivalent.
> The current RFCs do match the implementations, so it's really a design flaw in the RFCs not any bug in the implementations or doc per se.
> I think the issue of unexpected behavior isn't an errata per se, it's a protocol "flaw" (in some sense) that should be noted somehow.
> A HFDU errata would be one way to do that.  There may be other ways.
>
> -----Original Message-----
> From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Barry Leiba
> Sent: Monday, July 8, 2013 1:43 PM
> To: Adam Barth
> Cc: Dave Thaler; Bjoern Hoehrmann; RFC Errata System; presnick@qti.qualcomm.com; Jeff.Hodges@kingsmountain.com; http-state@ietf.org
> Subject: Re: [http-state] [Technical Errata Reported] RFC6265 (3663)
>
> Where are we on this?  Adam, Dave... should I mark this "Rejected"?
> Dave, do you still contend that this report is correct?  Or should some other change be proposed?
>
> Barry
>
> On Tue, Jun 18, 2013 at 5:29 AM, Adam Barth <ietf@adambarth.com>; wrote:
>> On Mon, Jun 17, 2013 at 5:45 PM, Dave Thaler <dthaler@microsoft.com>; wrote:
>>> Thanks Bjoern.
>>>
>>> Interesting, well in that case there may be an issue in the RFC 6265 algorithm for path matching.
>>> That's because it requires comparison for "identical" and "ab", "AB", "aB", and "Ab" are not "identical".
>>>
>>> So
>>> http://www.example.com/%AB/foo
>>> http://www.example.com/%ab/foo
>>> http://www.example.com/%Ab/foo
>>> http://www.example.com/%aB/foo
>>>
>>> are all "equivalent" in the language of RFC 3986, but not "identical" and hence a cookie on one will not match the others.
>>
>> The path-match algorithm does exactly what it says.  Even though RFC
>> 3986 might say that those strings are equivalent in some sense
>> (perhaps as URIs?), the path-match algorithm in RFC 6265 treats them
>> differently.  In particularly, they're not identical and the
>> path-match algorithm will likely return "false" for one or more of
>> them.
>>
>>> It may still be worth having an errata noting the above issue, even if it's Hold For Document Update.
>>
>> As far as I can tell, the errata is incorrect.
>>
>> On Mon, Jun 17, 2013 at 6:04 PM, Dave Thaler <dthaler@microsoft.com>; wrote:
>>> I checked with one of the test teams at Microsoft and got this back:
>>>
>>>> There is a gap in the RFCs 3986 and 6265. RFC 3986 talks about the
>>>> URI path and equivalence of encoded Unicode characters in the path section of the URI.
>>
>> I don't believe there is a gap.
>>
>>>> However, RFC 6265 section 5.1.4
>>>> does not specifically state that the pre-fix match should be done on the unescaped URL path.
>>
>> RFC 6265 gives a complete description of how to perform a path-match.
>> A compliant implementation will appear to operate as if it does
>> exactly what the specification says to do.  Given that RFC 6265
>> doesn't say to unescape the path, that means you ought not unescape
>> the path.
>>
>>>> All the browsers we tested against (IE, Chrome, Firefox) do this
>>>> case-sensitive prefix matching before sending the cookies to the other page.
>>
>> Indeed.
>>
>>>> For IIS applications created with Unicode characters, IIS converts
>>>> the escaped characters (like %0D%0C) to lower case, and they are
>>>> justified since the URI spec clearly calls out that they are equivalent.
>>
>> IIS is welcome to do that by the URI spec.  However, the strings are
>> not treated equivalently by RFC 6265.
>>
>>>> When one page re-directs to another in IIS application, the cookies
>>>> set for the first page are not presented to the application on the
>>>> other pages. This problem exists with the cookie handling by all the
>>>> browsers we tested against (IE, Chrome, Firefox). This is due to the gap I explained above.
>>
>> I don't see that as a problem.  All the implementations are
>> interoperating perfectly and matching the specification.  It sounds
>> like IIS has some undesirable behavior that its authors might want to
>> modify.  In any case, there's nothing to change about RFC 6265.  The
>> specification and the implementations are identical on this point.
>>
>> Adam
>>
>>
>>> -----Original Message-----
>>> From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]
>>> Sent: Monday, June 17, 2013 5:36 PM
>>> To: RFC Errata System
>>> Cc: abarth@eecs.berkeley.edu; barryleiba@computer.org;
>>> presnick@qti.qualcomm.com; Jeff.Hodges@kingsmountain.com; Dave
>>> Thaler; http-state@ietf.org
>>> Subject: Re: [http-state] [Technical Errata Reported] RFC6265 (3663)
>>>
>>> * RFC Errata System wrote:
>>>>Notes
>>>>-----
>>>>HEXDIG is defined in [RFC5234], Appendix B.1 as
>>>>  HEXDIG         =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
>>>>Note that lower case a-f are not legal.
>>>
>>> As per RFC 5234:
>>>
>>>    NOTE:
>>>
>>>       ABNF strings are case insensitive and the character set for these
>>>       strings is US-ASCII.
>>>
>>>    Hence:
>>>
>>>          rulename = "abc"
>>>
>>>    and:
>>>
>>>          rulename = "aBc"
>>>
>>>    will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and
>>>    "ABC".
>>> --
>>> Björn Höhrmann · mailto:bjoern@hoehrmann.de ·
>>> http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon:
>>> +49(0)160/4415681 · http://www.bjoernsworld.de
>>> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·
>>> http://www.websitedev.de/
>>>
>>>
>>>