W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2020

Re: [Technical Errata Reported] RFC7230 (5964)

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 24 Jan 2020 09:02:02 +1100
Cc: Roy Fielding <fielding@gbiv.com>, "Julian F. Reschke" <julian.reschke@greenbytes.de>, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, tpauly@apple.com, rick@openfortress.nl, ietf-http-wg@w3.org
Message-Id: <FF06904B-55AC-46C6-A20B-68FF435C98DC@mnot.net>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Rick,

This is better filed as an issue on the HTTP core revisions [1] than as an erratum.

Recommending REJECT.

Cheers,

1. https://github.com/httpwg/http-core#draft-http-core-documents


> On 24 Jan 2020, at 2:58 am, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC7230,
> "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5964
> 
> --------------------------------------
> Type: Technical
> Reported by: Rick van Rein <rick@openfortress.nl>
> 
> Section: 2.7.1
> 
> Original Text
> -------------
>   The URI generic syntax for authority also includes a deprecated
>   userinfo subcomponent ([RFC3986], Section 3.2.1) for including user
>   authentication information in the URI.  Some implementations make use
>   of the userinfo component for internal configuration of
>   authentication information, such as within command invocation
>   options, configuration files, or bookmark lists, even though such
>   usage might expose a user identifier or password.  A sender MUST NOT
>   generate the userinfo subcomponent (and its "@" delimiter) when an
>   "http" URI reference is generated within a message as a request
>   target or header field value.  Before making use of an "http" URI
>   reference received from an untrusted source, a recipient SHOULD parse
>   for userinfo and treat its presence as an error; it is likely being
>   used to obscure the authority for the sake of phishing attacks.
> 
> 
> Corrected Text
> --------------
>   The URI generic syntax for authority also includes a
>   userinfo subcomponent in which the format "user:password" is deprecated
>   ([RFC3986], Section 3.2.1).  The user is permitted, but the password
>   is not.  Some implementations make use
>   of the userinfo component for internal configuration of
>   authentication information, such as within command invocation
>   options, configuration files, or bookmark lists, even though such
>   usage might expose a user identifier or password.  A sender MUST NOT
>   generate a colon in a userinfo subcomponent when an
>   "http" URI reference is generated within a message as a request
>   target or header field value, but it may prefix a user and an "@" delimiter
>   before the host name in an "http" URI.  Before making use of an "http" URI
>   reference received from an untrusted source, a recipient SHOULD parse
>   for userinfo and treat the presence of a colon in it as an error.
> 
> 
> Notes
> -----
> RFC3986 does not forbid or even discourage the "user" in the userinfo subcomponent.  It only says
> 
>   Use of the format "user:password" in the userinfo field is
>   deprecated.
> 
> and continues to describe ":password" handling.
> 
> Obscuring the authority for the purposes of phishing is not mitigated by parsing the userinfo; subdomains in DNS offer similar notational flexibility.  Parsing does help against misleading password popups.
> 
> The user is part of the authority section of the URI and its purpose is to zoom in on a scope for authoritative resource addressing.  This syntax has in the past been (ab)used for Basic/Digest authentication details, which only works if visitor and visited resource happen to be the same user; it is this (ab)use that is now deprecated.
> 
> Instructions:
> -------------
> This erratum 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  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC7230 (draft-ietf-httpbis-p1-messaging-26)
> --------------------------------------
> Title               : Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
> Publication Date    : June 2014
> Author(s)           : R. Fielding, Ed., J. Reschke, Ed.
> Category            : PROPOSED STANDARD
> Source              : Hypertext Transfer Protocol Bis APP
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG

--
Mark Nottingham   https://www.mnot.net/
Received on Thursday, 23 January 2020 22:02:24 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 23 January 2020 22:02:25 UTC