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

[Amos Jeffries <[e-mail]>]

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