Re: [Unbearable] HTTPS Token Binding with TLS Terminating Reverse Proxies

[Amos Jeffries <[e-mail]>]

On 15/07/17 04:59, Brian Campbell wrote:
> Just a not-so-subtle reminder that HTTPS Token Binding with TLS 
> Terminating Reverse Proxies is one of the agenda items for Monday's 
> meeting in Prague and it would be great if there was some familiarity 
> with it going into the meeting. It's relativity short as drafts go, if 
> you're looking for something to read en route to the meeting: 
> https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-00 
> <https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-00>
> 

I wont be at the meeting. But reviewing anyway.


Several of the processing requirements in section 2.2 appear to be 
re-inventing already existing HTTP mechanisms without referencing them, 
nor integrating with them to support proxies that only implement HTTP - 
not TB.


Firstly;

Section 2.2 bullet item #1 places a normative MUST requirement on 
removing "Sec-Token-Binding" header from the clients request when 
forwarding.

Since the TLS connection is one "hop" this duplicates HTTP hop-by-hop 
header requirements. Such headers are governed by RFC 7230 section 6.1 
and required (also a normative MUST) to be listed in the HTTP Connection 
header by the sender. Such that even if the receiving proxy is not 
implementing this specification, it will still fail-safe by removing the 
header.


Secondly;

Section 2.2 bullet item #4 and the paragraph following it define the 
same behaviour for the "Provided-Token-Binding-ID" and 
"Referred-Token-Binding-ID" headers.


These two are not such a clear case of hop-by-hop since without the TLS 
there is the possibility of other hops between reverse-proxy and origin 
server. I believe it still worth at least referencing the HTTP 
Connection header as something that SHOULD be used to improve secure 
behaviour for messages containing those headers - the exception being 
when there are known to be multiple HTTP hops within the backend network.



NP: I know the TLS layer should be negotiating use of TB, so the sender 
"knows" the recipient implements this draft. But there is a possibility 
of the TLS decryption being done by other software than the HTTP 
processing, or opaquely relayed by an agent that negotiates TB, while 
the HTTP is processed by a proxy that does not support it. Use of the 
HTTP Connection header ensure the TB security is maintained even in 
those type of misconfiguration scenarios.

AYJ