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

Amos Jeffries <> Fri, 14 July 2017 21:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0FBC129B33 for <>; Fri, 14 Jul 2017 14:24:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.109
X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vyuzKL0IupgI for <>; Fri, 14 Jul 2017 14:23:59 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 2DD63129AA8 for <>; Fri, 14 Jul 2017 14:23:56 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPA id 9A38666044C; Sat, 15 Jul 2017 09:23:53 +1200 (NZST)
To: Brian Campbell <>, IETF Tokbind WG <>
References: <>
From: Amos Jeffries <>
Message-ID: <>
Date: Sat, 15 Jul 2017 09:23:52 +1200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Unbearable] HTTPS Token Binding with TLS Terminating Reverse Proxies
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Jul 2017 21:24:01 -0000

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: 
> <>

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.


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

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 


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.