W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2021

Benjamin Kaduk's Discuss on draft-ietf-httpbis-proxy-status-06: (with DISCUSS and COMMENT)

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
Message-ID: <162992649099.13537.15678016154076542531@ietfa.amsl.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

This archive was generated by hypermail 2.4.0 : Wednesday, 25 August 2021 21:21:46 UTC