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

Dave Thaler <dthaler@microsoft.com> Mon, 08 July 2013 20:56 UTC

Return-Path: <dthaler@microsoft.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 6304921F9CAB for <http-state@ietfa.amsl.com>; Mon, 8 Jul 2013 13:56:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.467
X-Spam-Level:
X-Spam-Status: No, score=-100.467 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, 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 ux7DIYS10a4f for <http-state@ietfa.amsl.com>; Mon, 8 Jul 2013 13:56:38 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id 87AC721F9DC0 for <http-state@ietf.org>; Mon, 8 Jul 2013 13:56:12 -0700 (PDT)
Received: from BN1AFFO11FD023.protection.gbl (10.58.52.204) by BN1BFFO11HUB013.protection.gbl (10.58.53.123) with Microsoft SMTP Server (TLS) id 15.0.717.3; Mon, 8 Jul 2013 20:55:29 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD023.mail.protection.outlook.com (10.58.52.83) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Mon, 8 Jul 2013 20:55:28 +0000
Received: from db9outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.3.136.1; Mon, 8 Jul 2013 20:54:40 +0000
Received: from mail212-db9-R.bigfish.com (10.174.16.238) by DB9EHSOBE013.bigfish.com (10.174.14.76) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 20:53:33 +0000
Received: from mail212-db9 (localhost [127.0.0.1]) by mail212-db9-R.bigfish.com (Postfix) with ESMTP id 3FCAD2E00FA for <http-state@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Mon, 8 Jul 2013 20:53:33 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -20
X-BigFish: PS-20(zz98dI9371Ic89bh542I1432Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah1954cbh8275bh8275dhz31h2a8h668h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh17ej9a9j1155h)
Received-SPF: softfail (mail212-db9: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=dthaler@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(199002)(189002)(24454002)(13464003)(51704005)(56776001)(74876001)(81342001)(4396001)(53806001)(47446002)(16406001)(33646001)(15202345003)(69226001)(16601075003)(83072001)(77096001)(74502001)(80022001)(74662001)(59766001)(79102001)(81542001)(76576001)(54356001)(31966008)(65816001)(56816003)(74316001)(76786001)(46102001)(77982001)(49866001)(74366001)(54316002)(74706001)(76482001)(76796001)(47976001)(63696002)(51856001)(47736001)(50986001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB271; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:4898:1a:3:985f:672a:51c3:e2a1; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail212-db9 (localhost.localdomain [127.0.0.1]) by mail212-db9 (MessageSwitch) id 1373316811253571_22562; Mon, 8 Jul 2013 20:53:31 +0000 (UTC)
Received: from DB9EHSMHS015.bigfish.com (unknown [10.174.16.226]) by mail212-db9.bigfish.com (Postfix) with ESMTP id 394CE80044; Mon, 8 Jul 2013 20:53:31 +0000 (UTC)
Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by DB9EHSMHS015.bigfish.com (10.174.14.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 8 Jul 2013 20:53:30 +0000
Received: from BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.329.3; Mon, 8 Jul 2013 20:53:30 +0000
Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) with Microsoft SMTP Server (TLS) id 15.0.731.11; Mon, 8 Jul 2013 20:53:27 +0000
Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.140]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.140]) with mapi id 15.00.0731.000; Mon, 8 Jul 2013 20:53:27 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: Barry Leiba <barryleiba@computer.org>, Adam Barth <ietf@adambarth.com>
Thread-Topic: [http-state] [Technical Errata Reported] RFC6265 (3663)
Thread-Index: AQHOa7sntVkCaDRzOU+sK+oTCvibR5k6oD8AgAABf9CAAJNXAIAgKwkAgAACGWA=
Date: Mon, 8 Jul 2013 20:53:27 +0000
Message-ID: <2ed31aa7639a49ffb9d689795335e88c@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>
In-Reply-To: <CALaySJL21aYDJKAq233FkZrUqk2H7uboo5GwgfURsB7hnRgkqQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:1a:3:985f:672a:51c3:e2a1]
x-forefront-prvs: 09011458FC
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BY2PR03MB271.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%QTI.QUALCOMM.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%KINGSMOUNTAIN.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%RFC-EDITOR.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%COMPUTER.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%ADAMBARTH.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%GMX.NET$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704005)(24454002)(377454003)(199002)(189002)(13464003)(15202345003)(20776003)(74662001)(47776003)(54316002)(79102001)(51856001)(77982001)(76796001)(59766001)(56816003)(46102001)(16601075003)(74502001)(76576001)(74876001)(69226001)(16676001)(76482001)(49866001)(81542001)(50466002)(77096001)(74706001)(83072001)(81342001)(47446002)(31966008)(54356001)(56776001)(74316001)(63696002)(4396001)(23756003)(47976001)(50986001)(6806003)(53806001)(76786001)(80022001)(65816001)(74366001)(33646001)(47736001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB013; H:TK5EX14HUBC107.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 09011458FC
X-Mailman-Approved-At: Mon, 08 Jul 2013 16:39:37 -0700
Cc: "http-state@ietf.org" <http-state@ietf.org>, "presnick@qti.qualcomm.com" <presnick@qti.qualcomm.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, 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: Mon, 08 Jul 2013 20:56:43 -0000

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