Intent to Ship: Token Binding

[Nick Harper]

This is a resumption of the thread from last April: https://groups.google.com/a/chromium.org/d/msg/blink-dev/r4zE8RKB6l4/wg7xJM5HAAAJ

Contact emails

nha...@chromium.org, awha...@chromium.org, van...@chromium.org

Spec

http://datatracker.ietf.org/doc/draft-ietf-tokbind-protocol/
http://datatracker.ietf.org/doc/draft-popov-tokbind-negotiation/
http://datatracker.ietf.org/doc/draft-ietf-tokbind-https/

Summary

Token Binding allows a site to cryptographically bind bearer tokens (such as Cookies) to the TLS layer, so that if a cookie is stolen, it can't be replayed by an attacker unless the attacker also has possession of the user's Token Binding private key for that site.  A more detailed threat model for Token Binding is described at https://docs.google.com/document/d/1ywYxiFT2A-BaTi6z45nqY9F4Ot5bk1_n-IACW1yK2g8. This is continuing work of the already-launched Channel ID feature in chrome. Token Binding has been behind a flag since M50, the subject of a Finch experiment for Canary and Dev since M51, and plans to go on by default in M58.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/jTwWj2Y_IPM/7tOHWa34C6EJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Debuggability

Token Binding includes an HTTP request header, which can be viewed in the Network tab of DevTools. Nothing else is provided for developers to debug Token Binding. Some concerns have been raised about Token Binding, https://docs.google.com/document/d/11lZGt584NbaJKGPVg080UjHv0DzanlyKgfsRp933AwA describes some of those concerns and comments on them.

Interoperability and Compatibility Risk

If support for Token Binding is removed from Chrome, then users who have tokens that were bound to a Token Binding key may need to obtain new bearer tokens (generally this will look like needing to reauthenticate to that site). I am assuming that sites will always have support for connections that do not support Token Binding, either for older browsers that lack Token Binding support, or for users who are behind a MitM, such as those using antivirus software or at an enterprise.

It is possible that some servers may choose to require Token Binding (and provide no access to protected resources without a valid Sec-Token-Binding header). Doing so would be hostile to users using browsers that don’t support Token Binding, or users who are behind a MitM (antivirus or enterprise). An operator of such a server might relax this hostility slightly by checking the User-Agent string in the request and only requiring Token Binding if the UA supports Token Binding (note that this is insecure because the UA string could be changed by a MitM). In this case, removing support from Chrome for Token Binding could break the expectations of site operators who don’t update the list of UAs that support Token Binding.

It is possible that most of the uses of Token Binding will be for enterprises. If adoption of Token Binding is mostly in enterprises, we will have very little insight into its use from client-side logging when making a decision to deprecate and remove it.

OWP launch tracking bug

Feature bug: crbug.com/467312
Launch bug: crbug.com/596699

Entry on the feature dashboard

https://www.chromestatus.com/feature/5097603234529280

[Ryan Sleevi]

One thing that I noticed was that it doesn't look like the Fetch spec has been updated - https://github.com/whatwg/fetch/issues/30 is still open and it looks like a ton of feedback remains unaddressed in https://github.com/whatwg/fetch/pull/325

Basically, a part of the spec is missing. I'm not sure how to evaluate what Chrome implemented against that, or how we might expect others to implement. Do you know if this is being addressed?

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACdeXiKbBGhNHtHRSWj5TSX1FpksEy8dXHgvM-6Q8J9ftvpo8g%40mail.gmail.com.

[Vinod Anupam]

On Thu, Jan 12, 2017 at 2:32 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

One thing that I noticed was that it doesn't look like the Fetch spec has been updated - https://github.com/whatwg/fetch/issues/30 is still open and it looks like a ton of feedback remains unaddressed in https://github.com/whatwg/fetch/pull/325

Basically, a part of the spec is missing. I'm not sure how to evaluate what Chrome implemented against that, or how we might expect others to implement. Do you know if this is being addressed?

Sorry, I let the Fetch pull request stall :(

I'll address the reviewer's comments and get that ball rolling again ASAP.

[Jochen Eisinger]

Please ping this thread again once you've addressed the outstanding feedback and want to go ahead with shipping!

thanks

-jochen

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.

[Nick Harper]

Since the original Intent to Implement for Token Binding was sent, the scope of what we're looking to implement and ship has changed. In addition to what was described in the Intent to Implement, we're looking to ship the following as well:

- All of draft-ietf-tokbind-https (including referred Token Bindings). There was a carve-out for those in the Intent to Implement.

- draft-ietf-tokbind-tls13 (https://tools.ietf.org/html/draft-ietf-tokbind-tls13-00)

- draft-ietf-tokbind-tls13-0rtt (https://datatracker.ietf.org/doc/draft-ietf-tokbind-tls13-0rtt/)

From looking at the aforementioned Fetch PR, it now also describes a JS api for referred Token Bindings which is out of scope for this Intent to Implement/Ship.

In parallel to getting the feedback on the Fetch spec resolved, I'm looking for feedback on this broader scope of work. Specifically, I'm interested in any feedback on the 0-RTT Token Binding part. Here are some things that I think might be points of concern with it: 1) the Internet-Draft has expired. 2) shipping it will require (at first) using a non-standard TLS extension code point; later this can be changed to the IANA assigned code point once such assignment happens. While we're waiting on a reply regarding the Fetch spec, is there any feedback/comments on this expanded scope?

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

[van...@chromium.org]

Hi all,

I have been through a few rounds of addressing reviewer feedback in the Token Binding in Fetch PR https://github.com/whatwg/fetch/pull/325  (Diff as of 04/13/2018)

(And expect only minor edits going forward.)

(Sorry, it took us a while to get here :-(  )

I'm requesting the needed LGTMs so we can unblock this Intent to Ship.

thanks,

-Anupam

[Vinod Anupam]

Hi all,

I have been through a few rounds of addressing reviewer feedback in the Token Binding in Fetch PR https://github.com/whatwg/fetch/pull/325  (Diff as of 04/13/2018)

(And expect only minor edits going forward.)

(Sorry, it took us a while to get here :-(  )

I'm requesting the needed LGTMs so we can unblock this Intent to Ship.

thanks,

-Anupam

[Anne van Kesteren]

On Mon, Apr 16, 2018 at 8:13 PM, Vinod Anupam <van...@google.com> wrote:
> I have been through a few rounds of addressing reviewer feedback in the
> Token Binding in Fetch PR https://github.com/whatwg/fetch/pull/325 (Diff as
> of 04/13/2018)
> (And expect only minor edits going forward.)
>
> (Sorry, it took us a while to get here :-( )

FWIW, it would help if you could open a new PR that has all the
commits squashed or some such as that PR seems to crash GitHub's
infrastructure and some folks have trouble loading it. I haven't been
able to review recently. It also seems that we still don't have
web-platform-tests.


--
https://annevankesteren.nl/

[Jochen Eisinger]

Hey,

two questions: one of the reasons given for deprecation channel ids was that they don't work with 0rtt. My understand is that the current iteration of token binding also doesn't work with 0rtt?

Also, are the bits that are being discussed in the fetch pr already implemented? If not, how does token binding interact with privacy mode?

thx

-jochen

[Nick Harper]

The portions of Token Binding that are currently implemented don't work with 0-RTT, but there is a plan to make Token Binding work with 0-RTT.

Everything but the JS API in the Fetch PR is implemented (I think): Token Binding is not used when in privacy mode, which should match the language in the Fetch PR to not do Token Binding when credentials=false.

[Yoav Weiss]

On Tue, Apr 17, 2018 at 11:38 AM Nick Harper <nha...@chromium.org> wrote:

The portions of Token Binding that are currently implemented don't work with 0-RTT, but there is a plan to make Token Binding work with 0-RTT.

Everything but the JS API in the Fetch PR is implemented (I think): Token Binding is not used when in privacy mode, which should match the language in the Fetch PR to not do Token Binding when credentials=false.

So, Token-bound credentialed requests are being sent over connections from the regular connection pool, right? 

[Nick Harper]

Yes, there's no extra segmentation of pools created for Token Binding.

I've heard discussion of Firefox considering sending requests both with and without cookies on the same connection, and this would be doable with Token Binding as well. (The current implementation in Chrome however makes use of the privacy mode split.)

[Jochen Eisinger]

It seems that Token Binding follows cookie host matching rules. I wonder whether we should add another bit whether a token was bound to a connection in the default port vs not, i.e., a token bound to a connection to port 443 wouldn't be send to a connect on port 31337, while one for port 80433 would be shared with 31337.

[van...@chromium.org]

I closed the original PR (#325), and created a fresh PR (#715) @  https://github.com/whatwg/fetch/pull/715

Anne, could you please let me know if anything else is needed?

On the tests front, we are blocked on WPT-usable TLS libraries that support Token Binding and are looking into options that will let us set up tests.

--
https://annevankesteren.nl/

[Anne van Kesteren]

On Thu, Apr 19, 2018 at 7:00 PM, <van...@chromium.org> wrote:
> I closed the original PR (#325), and created a fresh PR (#715) @
> https://github.com/whatwg/fetch/pull/715

Thank you! Now I can read it again.

> Anne, could you please let me know if anything else is needed?

Since I can't load the original PR it's a little unclear to me who has
reviewed it. There's quite a bit of editorial work remaining, but
before starting with that it'd be good to know if, e.g., Mike West is
satisfied with the semantics proposed in the PR, and whether we will
add the additional port restriction Jochen mentioned.

> On the tests front, we are blocked on WPT-usable TLS libraries that support
> Token Binding and are looking into options that will let us set up tests.

Thanks! I think it would be good to have this in place before landing
the Fetch PR as it'll help challenge the written work.


--
https://annevankesteren.nl/

[Jochen Eisinger]

wanted to give a quick heads-up that I'm trying to put together a meeting with some internal stakeholders to converge on some of the open questions. Will report back afterwards.