- From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
- Date: Wed, 25 Aug 2021 14:21:31 -0700
- To: "The IESG" <iesg@ietf.org>
- Cc: draft-ietf-httpbis-proxy-status@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, tpauly@apple.com, tpauly@apple.com
Benjamin Kaduk has entered the following ballot position for draft-ietf-httpbis-proxy-status-06: Discuss 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-proxy-status/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- draft-ietf-httpbis-semantics seems to require that in order to merge a trailer field into the header section, the field definition both explicitly permits the merging action "and defines how trailer field values can be safely merged." The discussion in §2 of this document about preserving ordering of trailer values relative to other intermediaries seems to imply that trailer fields will be merged into the header section (otherwise how could there be an order?), but I do not see a specification for how to safely perform the merge operation. Can we have more clarity on the expected behavior in this case? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Rich Salz for the secdir review, and the authors for making the indicated changes. I made a couple pull requests with some suggested edits at: https://github.com/httpwg/http-extensions/pull/1618 https://github.com/httpwg/http-extensions/pull/1619 Section 2.1.3 The "next-protocol" parameter's value indicates the ALPN protocol identifier [RFC7301] used by the intermediary to connect to the next hop. This is only applicable when that connection was actually established. The value MUST be either an sf-token or sf-binary, representing a TLS Application-Layer Protocol Negotiation (ALPN) Protocol ID (see I do know about "h2c" and Upgrade, but I think there are cases where neither TLS nor Upgrade is used. Is there some way to indicate, e.g., that HTTP/1.1 without TLS was used? I do not believe that setting "http/1.1" here has those semantics in the way that "h2c" does, and it seems that there may some value in indicating whether a secure transport was used for the next hop in a similar way to how setting "h2" or "h3" here would do so. [...] If the protocol identifier is able to be expressed as an sf-token using ASCII encoding, that form MUST be used. There seems to be some ossification risk of the sf-binary form is never used. I would hope that the use of structured fields mitigates that risk, since sf-binary support is needed in the generic field decoder, but I don't know that I would specifically rely on it. The MUST here prohibits greasing to be sure; maybe the benefit of consistency outweighs the risk, though. Section 2.3.13 TLS protocol errors are typically accompanied by a TLS alert message being generated; would the 'alert-id' and 'alert-message' extra parameters be applicable here (in addition to for "tls_alert_received" down in §2.3.15)? Section 2.3.15 - alert-message: an sf-token containing the applicable description string from the TLS Alerts registry. See [RFC8446]. I don't think there's a formal restriction on what characters are allowed in description strings in the TLS Alerts registry, so that, e.g., one could in theory have an alert description containing characters like ";" that are not allowed in an sf-token. It's so unlikely to happen in practice that I'm not actually concerned, but I will ask if we want to formally provide some behavior to allow for such cases. Section 2.3.24 - coding: an sf-token containing the specific coding that caused the error. Is it worth referencing the registry of such codings? Section 4 [I included some suggestions for additional detail in the security considerations in my PR, mentioned above] It is probably worth saying something about how there is no E2E validation of accuracy, e.g., a proxy could claim that it used a secure h2 or h3 transport for the next hop even though it didn't actually do so.
Received on Wednesday, 25 August 2021 21:21:45 UTC