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

[Dave Thaler <[e-mail]>]

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; [e-mail]; [e-mail]; [e-mail]
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: [e-mail] [mailto:[e-mail]] On Behalf Of Barry Leiba
Sent: Monday, July 8, 2013 1:43 PM
To: Adam Barth
Cc: Dave Thaler; Bjoern Hoehrmann; RFC Errata System; [e-mail]; [e-mail]; [e-mail]
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 <[e-mail]> wrote:
> On Mon, Jun 17, 2013 at 5:45 PM, Dave Thaler <[e-mail]> 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 <[e-mail]> 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:[e-mail]]
>> Sent: Monday, June 17, 2013 5:36 PM
>> To: RFC Errata System
>> Cc: [e-mail]; [e-mail]; 
>> [e-mail]; [e-mail]; Dave 
>> Thaler; [e-mail]
>> 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:[e-mail] · 
>> 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/
>>
>>
>>