[Errata Held for Document Update] RFC7230 (5964)
RFC Errata System <rfc-editor@rfc-editor.org> Wed, 05 February 2020 14:42 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2088F120059 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 5 Feb 2020 06:42:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level:
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXK543VEMdEy for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 5 Feb 2020 06:42:56 -0800 (PST)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542371200C7 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 5 Feb 2020 06:42:55 -0800 (PST)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1izLq5-0002y0-9b for ietf-http-wg-dist@listhub.w3.org; Wed, 05 Feb 2020 14:39:37 +0000
Resent-Date: Wed, 05 Feb 2020 14:39:37 +0000
Resent-Message-Id: <E1izLq5-0002y0-9b@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <wwwrun@rfc-editor.org>) id 1izLq1-0002x3-OO for ietf-http-wg@listhub.w3.org; Wed, 05 Feb 2020 14:39:33 +0000
Received: from rfc-editor.org ([4.31.198.49]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <wwwrun@rfc-editor.org>) id 1izLpu-0001Nk-68 for ietf-http-wg@w3.org; Wed, 05 Feb 2020 14:39:33 +0000
Received: by rfc-editor.org (Postfix, from userid 30) id 8515BF406D9; Wed, 5 Feb 2020 06:39:07 -0800 (PST)
To: rick@openfortress.nl, fielding@gbiv.com, julian.reschke@greenbytes.de
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: barryleiba@computer.org, iesg@ietf.org, ietf-http-wg@w3.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20200205143907.8515BF406D9@rfc-editor.org>
Date: Wed, 05 Feb 2020 06:39:07 -0800
Received-SPF: pass client-ip=4.31.198.49; envelope-from=wwwrun@rfc-editor.org; helo=rfc-editor.org
X-W3C-Hub-Spam-Status: No, score=-7.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1izLpu-0001Nk-68 8f5d09bf2287f44c53acbd340f51d298
X-Original-To: ietf-http-wg@w3.org
Subject: [Errata Held for Document Update] RFC7230 (5964)
Archived-At: <https://www.w3.org/mid/20200205143907.8515BF406D9@rfc-editor.org>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37340
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
The following errata report has been held for document update 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 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Rick van Rein <rick@openfortress.nl> Date Reported: 2020-01-23 Held by: Barry Leiba (IESG) 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. =========================== Verifier notes: This is not really an erratum, as the document says exactly what it was intended to say when it was written. That said, the issue does need to be discussed as the document is updated, and an update is planned... so I'm marking it "Held for Document Update", rather than "Rejected". -------------------------------------- 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
- [Errata Held for Document Update] RFC7230 (5964) RFC Errata System