Deprecation of too much userinfo (was: RFC7230 Errata 5964)

[vanrein]

The current semantics draft states

2.5.4. Deprecated userinfo

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.

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 the intricacies of ":password" handling.

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.

I have written an I-D about the http://user@ form that places it in a User: user header with the intention of adding user names in much the same manner as host names, as a selector for a naming scope of resources.

I believe that obscuring the authority for the purposes of phishing is not really mitigated by parsing the userinfo; subdomains in DNS offer similar notational flexibility. Parsing does help against misleading password popups, but these are probably easier to remedy when credential inquiries are only made in response to WWW-Authenticate and Proxy-Authenticate headers.

[mnot]

Discussed in Basel. Correcting the reasoning of why it was deprecated can be addressed editorially. Changing what was deprecated needs to be a much larger discussion and pull in the security community.