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

[John Bradley <[e-mail]>]

So it is valid in hop by hop for the proxy to pass on the original header information as its own for the next hop if that is the correct thing to do?

I suppose that is largely what happens with keep-alive.

To Andre’s point I understand that existing proxies wouldn't negotiate token binding but we need to cover creative future development.  
If we lever it open for a proxy to negotiate token binding on one side and pall along the header someone will do it and blame the spec as being unclear.

We would clearly never recommend that but won’t have direct control over developers.

John B.

> On Feb 9, 2017, at 4:14 PM, Amos Jeffries <[e-mail]> wrote:
> 
> On 9/02/2017 6:20 a.m., Andrei Popov wrote:
>> Ø  The Connect header is for the client to tell a proxy "this header
>> really doesn't make sense to forward, please drop it on the next
>> hop". …but in the case of the Sec-Token-Binding header, the client
>> does not know whether it makes sense to forward or not. The client,
>> generally, does not know whether the proxy or TLS terminator
>> validates bindings, passes them along for the application server to
>> validate, or strips them altogether.
>> 
> 
> The Connection header is not particularly about proxies. It is simply
> about distinguishing hop-by-hop things from end-to-end so any naive/old
> HTTP recipient can keep the relevant data secure in a fail-closed way.
> 
> Since the TLS is hop-by-hop the preferred behaviour ought to be a
> MUST/SHOULD for listing in Connection header to meet the RFC 7230
> conditions.
> 
> If the recipient happens to be TB-aware and non-validating (for any
> reason, not just TTRPs). Then RFC 7230 grants the ability to forward on
> both the Sec-Token-Binding and Connection:Sec-Token-Binding headers as
> being relevant to the next-hop it is using.
> 
> ie. the "(or replace it with the intermediary's own connection options
> for the forwarded message)" clause is what applies to non-validating
> recipients.
> 
> However the non-validating case should be an exception rather than the
> norm. Specifically called out as such for TTRPs etc.
> 
> 
> HTH
> Amos
> 
> _______________________________________________
> Unbearable mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/unbearable