Subject: [Unbearable] Potential privacy bug if Include-Referer-Token-Binding-ID is improperly implemented client-side

From: Nick Harper <[email-masked]>
Date: Fri, 11 Mar 2016 16:11:46 -0800

While implementing referred token bindings, I realized that if the client
doesn't handle the "Include-Referer-Token-Binding-ID" header correctly, it
could introduce a privacy bug that could result in an attacker MitMing
plaintext HTTP to trick the client into revealing to the attacker the
TokenBinding IDs for any site that does not use HSTS. This would happen if
the client doesn't check that the Include-Referer-Token-Binding-ID header
was sent in response to a request that had the Token-Binding header. I
don't know how likely others might run into this in implementation. If it's
a concern, the following wording could be added to the tbhttps spec:

"If the Include-Referer-Token-Binding-ID header is received in response to
a request that did not include the Token-Binding header, the client MUST
ignore the Include-Referer-Token-Binding-ID header."

---

From: Dirk Balfanz <[email-masked]>
Date: Mon, 21 Mar 2016 04:58:42 +0000

Hi Nick,

can you explain a little more? Let's say a client has a policy to not use
Token Binding with server A, but no such restrictions for server B. Let's
also say that A redirects to B with the Include-Referer-Token-Binding-ID
header. Now, the client would reveal to B, as a referred token binding, the
TokenBindingID it would normally use with A, even though there was no
Token-Binding header in the initial request to A (and it is not, in fact,
using any such TokenBindingID with A because of its policy).

Is there something wrong with that?

Dirk.

On Fri, Mar 11, 2016 at 4:12 PM Nick Harper <[email-masked]> wrote:

> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>

---

From: Nick Harper <[email-masked]>
Date: Sun, 20 Mar 2016 22:27:02 -0700

Here's the problem: Suppose the connection to server A is over http. Now a
network attacker B injects into some http page (from server C) code that
will cause the client to make an http request to server A. The attacker B
intercepts the request and responds with a redirect to server B (with the
Include-Referer-Token-Binding-ID header). The client dutifully follows that
request and forwards the TokenBindingID it has for A to the
attacker-controlled B. This is a problem, because A never intended to have
the client forward its TokenBindingID from A to B.

On Sun, Mar 20, 2016 at 9:58 PM, Dirk Balfanz <[email-masked]> wrote:

>> "If the Include-Referer-Token-Binding-ID header is received in response
>> to a request that did not include the Token-Binding header, the client MUST

---

From: Dirk Balfanz <[email-masked]>
Date: Mon, 21 Mar 2016 05:33:49 +0000

I see. The problem is that the *server* may not see its preferences honored
if there is a MITM.

Let me add this sentence to the spec.

Dirk.

On Sun, Mar 20, 2016 at 10:27 PM Nick Harper <[email-masked]> wrote:

>>> While implementing referred token bindings, I realized that if the
>>> client doesn't handle the "Include-Referer-Token-Binding-ID" header
>>> correctly, it could introduce a privacy bug that could result in an
>>> attacker MitMing plaintext HTTP to trick the client into revealing to the
>>> attacker the TokenBinding IDs for any site that does not use HSTS. This
>>> would happen if the client doesn't check that the
>>> Include-Referer-Token-Binding-ID header was sent in response to a request
>>> that had the Token-Binding header. I don't know how likely others might run
>>> into this in implementation. If it's a concern, the following wording could
>>> be added to the tbhttps spec:
>>>