Subject: [Technical Errata Reported] RFC7230 (5964)

From: RFC Errata System <[email-masked]>
Date: Thu, 23 Jan 2020 07:58:40 -0800 (PST)

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

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

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Jan 2020 09:02:02 +1100

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

--
Mark Nottingham   https://www.mnot.net/

---

From: Rick van Rein <[email-masked]>
Date: Thu, 23 Jan 2020 23:26:02 +0100

Hello Mark,

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

It is a mixture of technically incorrect application of RFC 3986 and
suggestions how HTTP should handle this; is what you are saying that
this is too much a mixture?

I was not sure how to bring this forward, and still am not sure.  I am
writing a positive alternative in draft-vanrein-http-unauth-user -- is
that more in line with your take on this?

Cheers,

Rick van Rein
InternetWide.org

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Jan 2020 09:29:09 +1100

Hi Rick,

I'm saying that those documents are actively under revision now, so the appropriate place to discuss it is in that effort, not as an erratum against the soon-to-be-obsoleted specification.

Cheers,

> On 24 Jan 2020, at 9:26 am, Rick van Rein <[email-masked]> wrote:
> 
> Hello Mark,
>

---

From: Rick van Rein <[email-masked]>
Date: Fri, 24 Jan 2020 09:37:28 +0100

Hello Mark,

I've created issue #278 under the HTTPbis repository.  I don't know how
to process that while flagging down the Errata, but perhaps adding the
link to the issue is useful:

https://github.com/httpwg/http-core/issues/278

I have cloned the repository and will create a Pull Request with text
that I think is more justified.

Thanks,
 -Rick

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Jan 2020 07:39:38 +0100

> I'm saying that those documents are actively under revision now, so the appropriate place to discuss it is in that effort, not as an erratum against the soon-to-be-obsoleted specification.

Yes.

But we have to deal with the erratum in any case. I believe that what
RFC 7230 says is intentional, so within the scope of the erratum we
should deal with adjusting the prose referring to RFC 3986. Thus "Held
For Update".

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 29 Jan 2020 17:40:09 +1100

Fair enough.

> On 29 Jan 2020, at 5:39 pm, Julian Reschke <[email-masked]> wrote:
>

---

From: Rick van Rein <[email-masked]>
Date: Wed, 29 Jan 2020 17:16:12 +0100

Hello,

This works for me, and sounds proper -- it formally transfers the work
to the newly posted issue on GitHub.

-Rick