Roman Danyliw's Yes on draft-ietf-httpbis-semantics-16: (with COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Thu, 10 June 2021 12: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 5AE7C3A11DD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 10 Jun 2021 05:42:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Level:
X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 W5mwb40cwXca for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 10 Jun 2021 05:42:41 -0700 (PDT)
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 189833A11D8 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 10 Jun 2021 05:42:40 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1lrJr9-0005aE-3b for ietf-http-wg-dist@listhub.w3.org; Thu, 10 Jun 2021 12:32:26 +0000
Resent-Date: Thu, 10 Jun 2021 12:32:19 +0000
Resent-Message-Id: <E1lrJr9-0005aE-3b@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 <noreply@ietf.org>) id 1lrJov-000533-D9 for ietf-http-wg@listhub.w3.org; Thu, 10 Jun 2021 12:30:14 +0000
Received: from mail.ietf.org ([4.31.198.44]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <noreply@ietf.org>) id 1lrJnw-0000WT-QO for ietf-http-wg@w3.org; Thu, 10 Jun 2021 12:29:57 +0000
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCE83A1132; Thu, 10 Jun 2021 05:28:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-httpbis-semantics@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, tpauly@apple.com, tpauly@apple.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.31.0
Auto-Submitted: auto-generated
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <162332812816.1576.8653380065166819501@ietfa.amsl.com>
Date: Thu, 10 Jun 2021 05:28:48 -0700
Received-SPF: pass client-ip=4.31.198.44; envelope-from=noreply@ietf.org; helo=mail.ietf.org
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1lrJnw-0000WT-QO ce4fd14a2349b4750e15efdee6c03ce1
X-Original-To: ietf-http-wg@w3.org
Subject: Roman Danyliw's Yes on draft-ietf-httpbis-semantics-16: (with COMMENT)
Archived-At: <https://www.w3.org/mid/162332812816.1576.8653380065166819501@ietfa.amsl.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38879
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>
Roman Danyliw has entered the following ballot position for draft-ietf-httpbis-semantics-16: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-httpbis-semantics/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** Section 2.2. Per “Additional (social) requirements are placed on implementations …”, what’s a “social” requirement? ** Section 4.2.2. Resources made available via the "https" scheme have no shared identity with the "http" scheme. They are distinct origins with separate namespaces. However, an extension to HTTP that is defined to apply to all origins with the same host, such as the Cookie protocol [RFC6265], can allow information set by one service to impact communication with other services within a matching group of host domains. It would be worth reiterating that it might be risky for extensions to treat http + https origins on the same host uniformly. ** Section 5.1. Convention question. Per “Field names … ought to be registered within the …” HTTP field name registry, I have a question about the strength of the recommendation based on the use of the verb “ought” – is that RECOMMENDED? SHOULD? Section 8.3.1, 8.3.2, 8.4.1, 8.8.3, etc use a similar construct. ** Section 7.2. Does this text allow for the possibility for both a Host and :authority be included? ** Section 9.2.1. In addition to example of the access logs files filling the disk, there could be significant CPU load if the target is a script. ** Section 17.1. The text provides helpful caution by stressing that “… the user's local name resolution service [is used] to determine where it can find authoritative responses. This means that any attack on a user's network host table, cached names, or name resolution libraries becomes an avenue for attack on establishing authority for "http" URIs.” The subsequent text highlights DNSSEC as improving authenticity. It seems that the integrity provided by DoT or DoH would also be relevant. ** Section 17.2 Users need to be aware that intermediaries are no more trustworthy than the people who run them; HTTP itself cannot solve this problem. No disagreement with the sentiment, but I would recommend not framing it in term of the trustworthiness of the _people_ (i.e., intermediaries with poor security or privacy practices is not necessarily due to the lack of trustworthiness of the engineers operating the service; perhaps these services are also run in of jurisdictions where confidence in them should be reduced). NEW Users need to be aware that intermediaries are no more trustworthy that the entities that operate them and the policies governing them; HTTP itself cannot solve this problem. ** Section 17.5. More generically describe the attack OLD Failure to limit such processing can result in buffer overflows, arithmetic overflows, or increased vulnerability to denial-of-service attacks. NEW Failure to limit such processing can result in arbitrary code execution due to a buffer overflows or arithmetic overflows; or increased vulnerability to denial-of-service attacks. ** Editorial -- Section 3.5. Should s/advance configuration choices/advanced configuration choices/? -- Section 4.2.2. A client MUST ensure that its HTTP requests for an "https" resource are secured, prior to being communicated, and that it only accepts secured responses to those requests. Note that the definition of what cryptographic mechanisms are acceptable to client and server are usually negotiated and can change over time. This text goes from referring to “secured” in the first sentence to “[acceptable] cryptographic mechanisms” in the second sentence. To link them, perhaps s/are secured/are cryptographically secured/ -- Section 6.5. Typo. s/section_ are are/section_ are/ -- Section 11.1. The text (at least when read as a .txt) isn’t showing RFC7617 or RFC7616 as references. -- Section 14.1.1. Typo. s/gramar/grammar/
- Roman Danyliw's Yes on draft-ietf-httpbis-semanti… Roman Danyliw via Datatracker