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

[John Bradley <[e-mail]>]

Are connection headers normally used in the reverse proxy use case?   Generally the user agent wouldn't know that it was talking to a proxy.

I thought that they were more for the forward proxy use case where the browser is configured to talk to a specific proxy or is transparently intercepted (man/enterprise in the middle) 

I could hypothetically see a enterprise proxy creating token binding Id’s for the connections to servers and mapping those to token binding ID from the browser. 

I think the NGNX token binding module (https://github.com/google/ngx_token_binding <https://github.com/google/ngx_token_binding>) is doing that sort of transparent mapping on the server side for session cookies. 

We probably don't want the same behaviour for both forward and reverse proxies.

John B.


> On Feb 7, 2017, at 7:38 PM, Andrei Popov <[e-mail]> wrote:
> 
> When we discussed this early on, there was a strong distaste for connection headers in the HTTP community, so we've defined TB headers as per-request.
> " clients MUST include the Sec-Token-
>   Binding header field in their HTTP requests."
> We could also explicitly prohibit listing TB headers in the Connection header, if folks would like to see this clarification. 
> There are many reasons to keep TB headers per-request; it's not just about the proxies and terminators.
> 
> Cheers,
> 
> Andrei
> 
> -----Original Message-----
> From: Unbearable [mailto:[e-mail]] On Behalf Of =JeffH
> Sent: Tuesday, February 7, 2017 2:15 PM
> To: IETF TokBind WG <[e-mail]>
> Subject: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field?
> 
> 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
> 
> _______________________________________________
> Unbearable mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/unbearable