[Unbearable] Binding tokens to scope in HTTP

[Nick Sullivan <[e-mail]>]

The token binding header does not have any identity bound to it. This is
potentially problematic because it makes it much more likely that this
protocol is vulnerable to unknown key share issues.

Unknown key share attacks happen when a public key is used without binding
it to an identity by a signature. For example, Richard Barnes recently
published a draft describing how DANE with raw keys was vulnerable to this
style of: https://tools.ietf.org/html/draft-barnes-dane-uks-00.

In section 2.1. of draft-ietf-tokbind-https, the key pair scoping is
defined to be eTLD+1. Depending on the threat model, this requirement can
be subverted.

Consider an attacker who has access to read and modify headers, but not
private keys. Imagine a buggy/malicious service worker or something else of
this sort. Now imagine a site with a.example.com and b.example.com and a
wildcard *.example.com certificate. The attacker can take token binding
headers from a.example.com and put them on requests to b.example.com and
the cookies set on b.example.com will be bound to a.example.com's key.

This doesn't sound like a large issue, but it's indicative of the type of
subtle problems not binding the key to a context can cause.

If the token context was bound to the scope by including the eTLD+1 in the
(or the origin if the browser intends to use stricter token scoping), *and*
this scope was covered by the signature then this would not be possible.
The server could check the host header against the token context and then
refuse the token binding for new cookies.

A logical place to put this would be in the extensions of the token binding
structure, but unfortunately the extensions is not signed and so can be
modified. Is there a reason the extensions field of the TokenBinding
structure is not signed by the private key?

Nick