Re: [Technical Errata Reported] RFC7230 (5964)

[Mark Nottingham <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 
> 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/