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

[=JeffH <[e-mail]>]

 >> I agree with this for security considerations reasons -- we want
 >> the Sec-Token-Binding header to be hop-by-hop in sync with the
 >> underlying TLS connection and not be "leaked" downstream unless it
 >> is a conscious decision, e.g., in the tls terminating reverse proxy
 >> (TTRP) case.
 >>
 >>
 > But the client is only making a connection to a server and client
 > does not know whether it makes sense for that server to forward or
 > not. And it shouldn't know that.

correct, agreed.

 > Sec-Token-Binding shouldn't be listed in Connection header field by
 > a client.

listing Sec-Token-Binding in the Connection header means ([RFC7230] 
Section 6.1)..

    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.

..which is what we want by default for security considerations reasons, 
I think.

As Dirk noted:
  >
  > If the proxy has qualms about violating the spec by forwarding the
  > Sec-Token-Binding header despite its being listed in the Connect
  > header, it can always just use a different header name, like
  > "Private-Forwarded-Token-Binding", or whatever - some  mechanism
  > proprietary to the proxy and downstream server.

Thus, a comment on 
<https://tools.ietf.org/html/draft-campbell-tokbind-tls-term> (which 
i'll endeavor to write up more fully anon) is that it should either 
define another header field for conveyance of the 
EncodedTokenBindingMessage (along with the header field it already 
defines) or have the header field it already defines convey both the 
EncodedTokenBindingMessage and the EKM et al.

=JeffH