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

[RFC Errata System]

The following errata report has been submitted for RFC6265,
"HTTP State Management Mechanism".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6265&eid=3663

--------------------------------------
Type: Technical
Reported by: Dave Thaler <dth...@microsoft.com>

Section: 2.2

Original Text
-------------
The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTLs (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), NUL (null octet),

Corrected Text
--------------
The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTLs (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F), LF (line feed), NUL (null octet),

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.

That leaves two possible meanings: (1) that HEXDIG is correct and the text in 2.2 is wrong in suggesting a-f are legal, or (2) that a-f are legal and that a different definition of HEXDIG was intended than the one referenced.

This ambiguity is resolved in RFC 6265 section 5.1.4 which says:
" 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."
This section does no case normalization, nor any case-insensitive comparison of the path. The path is case sensitive and the comparison is for "identical".
Thus, the hex letters in HEXDIG must be case sensitive, and thus the only interpretation of HEXDIG that is consistent with this test for "identical" is the one that does not allow both upper-case and lower-case.

For comparison, RFC 3986 (and its predecessor RFC 2234) also have the same restriction of HEXDIG only supporting upper case, although RFC 3986 contains the additional explanation:
" pct-encoded = "%" HEXDIG HEXDIG

The uppercase hexadecimal digits 'A' through 'F' are equivalent to
the lowercase digits 'a' through 'f', respectively. If two URIs
differ only in the case of hexadecimal digits used in percent-encoded
octets, they are equivalent. For consistency, URI producers and
normalizers should use uppercase hexadecimal digits for all percent-
encodings."

Although the URI syntax in RFC 3986 disallows lower-case hex digits, the above text nonetheless says that such a string would be "equivalent". This is in contrast to RFC 6265 which requires the match to be "identical", not just "equivalent".

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC6265 (draft-ietf-httpstate-cookie-23)
--------------------------------------
Title : HTTP State Management Mechanism
Publication Date : April 2011
Author(s) : A. Barth
Category : PROPOSED STANDARD
Source : HTTP State Management Mechanism
Area : Applications
Stream : IETF
Verifying Party : IESG
_______________________________________________
http-state mailing list
http-...@ietf.org
https://www.ietf.org/mailman/listinfo/http-state

[Bjoern Hoehrmann]

* 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:bjo...@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/

[Adam Barth]

On Mon, Jun 17, 2013 at 5:45 PM, Dave Thaler <dth...@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 <dth...@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

[Dave Thaler]

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.

It may still be worth having an errata noting the above issue, even if it's Hold For Document Update.

-Dave

-----Original Message-----
From: Bjoern Hoehrmann [mailto:derh...@gmx.net]
Sent: Monday, June 17, 2013 5:36 PM
To: RFC Errata System
Cc: aba...@eecs.berkeley.edu; barry...@computer.org; pres...@qti.qualcomm.com; Jeff....@kingsmountain.com; Dave Thaler; http-...@ietf.org
Subject: Re: [http-state] [Technical Errata Reported] RFC6265 (3663)

[Dave Thaler]

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. However, RFC 6265 section 5.1.4

> does not specifically state that the pre-fix match should be done on the unescaped URL path.

> All the browsers we tested against (IE, Chrome, Firefox) do this case-sensitive prefix matching
> before sending the cookies to the other page.
>

> 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. 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.

Hope the above info is useful.

-Dave

-----Original Message-----
From: Dave Thaler
Sent: Monday, June 17, 2013 5:45 PM
To: 'Bjoern Hoehrmann'; RFC Errata System
Cc: aba...@eecs.berkeley.edu; barry...@computer.org; pres...@qti.qualcomm.com; Jeff....@kingsmountain.com; http-...@ietf.org
Subject: RE: [http-state] [Technical Errata Reported] RFC6265 (3663)

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.

It may still be worth having an errata noting the above issue, even if it's Hold For Document Update.

-Dave

-----Original Message-----
From: Bjoern Hoehrmann [mailto:derh...@gmx.net]
Sent: Monday, June 17, 2013 5:36 PM
To: RFC Errata System
Cc: aba...@eecs.berkeley.edu; barry...@computer.org; pres...@qti.qualcomm.com; Jeff....@kingsmountain.com; Dave Thaler; http-...@ietf.org
Subject: Re: [http-state] [Technical Errata Reported] RFC6265 (3663)

[Barry Leiba]

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

[Barry Leiba]

> 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.

If you have a proposal for a change to your errata report, I can edit
it and change it, and then mark it HFDU. Alternatively, I can just
mark this "Rejected" and let you sort out an alternative.

b

[Dave Thaler]

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.

[Dave Thaler]

Give me a few days to recover from backlog after vacation / US holidays.

-Dave

-----Original Message-----
From: barry...@gmail.com [mailto:barry...@gmail.com] On Behalf Of Barry Leiba
Sent: Monday, July 8, 2013 2:04 PM
To: Dave Thaler
Cc: Adam Barth; Bjoern Hoehrmann; RFC Errata System; pres...@qti.qualcomm.com; Jeff....@kingsmountain.com; http-...@ietf.org
Subject: Re: [http-state] [Technical Errata Reported] RFC6265 (3663)

[Dave Thaler]

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

[Barry Leiba]

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

[Dave Thaler]

Edited version looks good to me.

Thanks,
-Dave

> -----Original Message-----
> From: barry...@gmail.com [mailto:barry...@gmail.com] On Behalf Of
> Barry Leiba

> Sent: Wednesday, August 7, 2013 12:04 PM
> To: Dave Thaler