Re: [Unbearable] Sec- prefix for Token-Binding headers

[Ilari Liusvaara <[e-mail]>]

On Tue, Jun 30, 2015 at 10:09:41AM +0000, Dirk Balfanz wrote:
> 
> following Leif's request to mirror discussions here, I wanted to point out
> one discussion we're having over there regarding the Sec- prefix for the
> Token-Binding header:
> https://github.com/TokenBinding/Internet-Drafts/issues/1
> 
> Anne favors a Sec- prefix (meaning it can't be set directly from
> Javascript), whereas Martin doesn't.

Because TokenBinding protects cookies, and cookies are already a
forbidden field (that is, Javascript can't set its own cookies
for request), I don't see use for non-Sec field.

Referred token bindings might be another matter (especially if not
actually validated), since the access token might not take the form
of cookie, and thus Javascript can control sending/receiving.


Being able to set TokenBinding header from Javascript might however
lead to weird behaviour:

Generate a key and valid signature with that key. Then override
TokenBinding header with that signature on request to another origin
with cookies sent.

If browser has cookies for the origin, those now get sent with
invalid TokenBinding. Which should be no problem, unless the server
does something dumb.

If the server sends cookies and browser stores those, the
TokenBinding for those cookies will be wrong and those cookies
presumably won't work.


-Ilari