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

From: RFC Errata System <[email-masked]>
Date: Mon, 17 Jun 2013 17:28:30 -0700 (PDT)

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 <[email-masked]>

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

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 18 Jun 2013 02:36:22 +0200

>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:[email-masked] · 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/

---

From: Adam Barth <[email-masked]>
Date: Tue, 18 Jun 2013 02:29:04 -0700

On Mon, Jun 17, 2013 at 5:45 PM, Dave Thaler <[email-masked]> 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 <[email-masked]> 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:[email-masked]]
> Sent: Monday, June 17, 2013 5:36 PM
> To: RFC Errata System
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Dave Thaler; [email-masked]
> Subject: Re: [http-state] [Technical Errata Reported] RFC6265 (3663)
>
> Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de

---

From: Dave Thaler <[email-masked]>
Date: Tue, 18 Jun 2013 00:45:08 +0000

Thanks Bjoern.

So 

-Dave

-----Original Message-----
From: Bjoern Hoehrmann [mailto:[email-masked]] 
Sent: Monday, June 17, 2013 5:36 PM
To: RFC Errata System
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Dave Thaler; [email-masked]
Subject: Re: [http-state] [Technical Errata Reported] RFC6265 (3663)

As per RFC 5234:

   NOTE:

   Hence:

         rulename = "abc"

   and:

         rulename = "aBc"

---

From: Dave Thaler <[email-masked]>
Date: Tue, 18 Jun 2013 01:04:59 +0000

I checked with one of the test teams at Microsoft and got this back:

> encoded Unicode characters in the path section of the URI. However, RFC 6265 section 5.1.4 
> are equivalent. When one page re-directs to another in IIS application, the cookies set for the

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: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [http-state] [Technical Errata Reported] RFC6265 (3663)

Thanks Bjoern.

So 

-Dave

-----Original Message-----
From: Bjoern Hoehrmann [mailto:[email-masked]] 
Sent: Monday, June 17, 2013 5:36 PM
To: RFC Errata System
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Dave Thaler; [email-masked]
Subject: Re: [http-state] [Technical Errata Reported] RFC6265 (3663)

As per RFC 5234:

   NOTE:

   Hence:

         rulename = "abc"

   and:

         rulename = "aBc"