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

From: Dirk Balfanz <[email-masked]>
Date: Tue, 30 Jun 2015 10:09:41 +0000

Hi guys,

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.

I find Anne's arguments persuasive.

Any other thoughts?

Dirk.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 30 Jun 2015 13:32:00 +0300

> 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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Jun 2015 09:41:09 -0700

This is wholly confused, as I explained in the issue.  The security of
token binding is based on the private key.  If it is not, then I think
we need to discuss how that is not sufficient.

On 30 June 2015 at 03:09, Dirk Balfanz <[email-masked]> wrote:
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>