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

[Brian Campbell <[e-mail]>]

The "Sec-Token-Binding" header is defined in
https://tools.ietf.org/html/draft-ietf-tokbind-https and the WG decided not
to list "Sec-Token-Binding" in the Connection header field in that
document. https://mailarchive.ietf.org/arch/search/?email_list=
unbearable&q=%22on+not+listing+%27Sec-Token-Binding%
27+in+the+Connection+header+field%3F%22 will turn up at least some of that
discussion. It wouldn't make sense for this draft to require different
behavior of the client. Especially when the client won't know (and
shouldn't know) if it's talking to a reverse proxy or not.

"Provided-Token-Binding-ID" and "Referred-Token-Binding-ID" are not
hop-by-hop. They are providing info from the TTRP to the backend, whatever
that backend is. And the backend may involve additional layers of proxies
or it may not. But that's beyond the scope of this document.





On Fri, Jul 14, 2017 at 3:23 PM, Amos Jeffries <[e-mail]> wrote:

> 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/dr
>> aft-campbell-tokbind-ttrp-00 <https://tools.ietf.org/html/d
>> raft-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
>

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*