[Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field?

[=JeffH <[e-mail]>]

the below is kind of long (read it anyway :)  The summary is we need to 
make a conscious decision regarding the Connection HTTP request header 
field and whether we provide guidance regarding it and the 
Sec-Token-Binding header (and what guidance if so), or not. This seems 
to have ramifications for the nascent draft-campbell-tokbind-tls-term 
draft, unless I'm misunderstanding things.

=JeffH

In working through the list of "Considerations for New Header Fields" at 
the end of rfc7231 section 8.3.1 [1], there are these two items..

    o  Whether it is appropriate to list the field-name in the Connection
       header field (i.e., if the header field is to be hop-by-hop; see
       Section 6.1 of [RFC7230]).

    o  Under what conditions intermediaries are allowed to insert,
       delete, or modify the field's value.

Given the specifics in [RFC7230] Section 6.1 [2]..

   6.1.  Connection

    The "Connection" header field allows the sender to indicate desired
    control options for the current connection.  In order to avoid
    confusing downstream recipients, a proxy or gateway MUST remove or
    replace any received connection options before forwarding the
    message.

    When a header field aside from Connection is used to supply control
    information for or about the current connection, the sender MUST list
    the corresponding field-name within the Connection header field.  A
    proxy or gateway MUST parse a received Connection header field before
    a message is forwarded and, for each connection-option in this field,
    remove any header field(s) from the message with the same name as the
    connection-option, and then remove the Connection header field itself
    (or replace it with the intermediary's own connection options for the
    forwarded message).

    Hence, the Connection header field provides a declarative way of
    distinguishing header fields that are only intended for the immediate
    recipient ("hop-by-hop") from those fields that are intended for all
    recipients on the chain ("end-to-end"), enabling the message to be
    self-descriptive and allowing future connection-specific extensions
    to be deployed without fear that they will be blindly forwarded by
    older intermediaries.

..it offhand seems that one would want to list "Sec-Token-Binding" in 
the Connection header field because Sec-Token-Binding is ostensibly 
about the connection and is hop-by-hop because TLS is hop-by-hop.

However, given our current thinking wrt TB and TLS Terminating Reverse 
Proxies [3], where we are contemplating one approach where such "TTRPs" 
pass-through the Sec-Token-Binding header field and add a corresponding 
Token-Binding-Context header, one would not want to list 
Sec-Token-Binding in the Connection header (because a TTRP would then 
strip it off). However there are implementation and security 
considerations with this.

As one proposal, we could say in HTTPSTB something along the lines of..

   [...]
   Clients SHOULD NOT list the Sec-Token-Binding header field as
   a connection option in the Connection header field (Section 6.1
   of [RFC7230]) in order to generally enable Sec-Token-Binding
   header field pass-through by intermediaries, e.g., by TLS
   terminating reverse proxies (TTRP). Intermediaries MUST NOT
   modify the Sec-Token-Binding header field's value. See also the
   security considerations section.
   [...]
   Security Considerations
   [...]
   Not listing Sec-Token-Binding in the Connection header: this
   enables TTRPs to transparently convey the Sec-Token-Binding header
   field, containing a Token Binding Message, to the next tier ("backend
   servers"), e.g., where security tokens containing Token Binding IDs
   may be minted and validated. The communication between a TTRP and
   backend servers needs to be secured against eavesdropping and
   modification by unintended parties. The Token Binding Message itself
   may be validated by the TTRP or by a backend server. Though, in the
   latter case, the data necessary to perform such validation (i.e., the
   EKM, etc.) needs to be conveyed to the entity performing it. Such
   conveyance is out of scope for this specification.

   Listing Sec-Token-Binding in the Connection header: if done, this
   may help in ensuring that Token Binding IDs are not inadvertently
   revealed to unintended parties, though may cause difficulties with
   web sites employing TTRPs.
   [...]

Or, we could just say "clients SHOULD list the Sec-Token-Binding header 
field as a connection option in the Connection header field", but that 
will create problems for TTRPs [3].

Or, we can just not mention the Connection header and see if anyone 
raises questions about it during further WG and IETF-wide review.

thoughts?

[1] <https://tools.ietf.org/html/rfc7231#section-8.3.1>

[2] <https://tools.ietf.org/html/rfc7230#section-6.1>

[3] <https://tools.ietf.org/html/draft-campbell-tokbind-tls-term>