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

[John Bradley <[e-mail]>]

The other option might be to go back to having the reverse proxy validate the token binding and allow the client to list the Sec-Token-Binding header.

That would be hop by hop semantic.    

We should at-least document why we think that is a bad idea so we have something to point to if the issue comes up.

John B.


> On Feb 7, 2017, at 7:15 PM, =JeffH <[e-mail]> wrote:
> 
> 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>
> 
> 
> _______________________________________________
> Unbearable mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/unbearable