Intent to Remove: Token Binding

5,076 views
Skip to first unread message

Nick Harper

unread,
Aug 1, 2018, 1:36:10 PM8/1/18
to blink-dev, net-dev

Primary eng (and PM) emails

nha...@chromium.org


Links to other Intents threads

Intent to Implement: https://groups.google.com/a/chromium.org/d/topic/blink-dev/jTwWj2Y_IPM/discussion

Intent to Ship (take 1): https://groups.google.com/a/chromium.org/d/topic/blink-dev/r4zE8RKB6l4/discussion

Intent to Ship (take 2): https://groups.google.com/a/chromium.org/d/topic/blink-dev/C-iuVJeDGkk/discussion


Summary

Token Binding is a feature that has been behind a flag for over two years and has never shipped. (No Intent to Ship for Token Binding ever got approved.) I plan to remove all code related to this unused feature.


Motivation

After weighing the security benefit of Token Binding against the engineering costs, maintenance costs, web compatibility risk, and adoption, it does not make sense to ship this feature.


Interoperability and Compatibility Risk

There is little risk to removing this feature. It has never been on by default, and there has been little industry adoption. Edge is the only other browser that supports Token Binding; Chrome will behave as any other browser that does not support Token Binding.


Edge: Supported, negative to removal

Firefox: not supported

Safari: not supported


Alternative implementation suggestion for web developers

Depending on the use case that a site operator had for Token Binding, there are other technologies that can be used. For protecting cookies against XSS, the HttpOnly flag can be used. For providing a cryptographic assertion that both peers are on the same connections, TLS client certificates can be used. Some use cases might be able to use WebCrypto.


Usage information from UseCounter

No information from UseCounter. Based on the Net.TokenBinding.Support UMA histogram, less than 00.01% of HTTPS requests on Stable had Token Binding attempted. This indicates that very few people flipped the flag in about:flags for Token Binding.


Entry on the feature dashboard

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



Chris Harrelson

unread,
Aug 6, 2018, 8:36:59 PM8/6/18
to nha...@chromium.org, blink-dev, net-dev
Hi,

FYI: since this feature never shipped by default, you do not need any approvals from the API owners.

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

bcam...@pingidentity.com

unread,
Aug 14, 2018, 3:49:18 PM8/14/18
to blink-dev, net...@chromium.org
I would like to respectfully ask (or maybe beg) that removal be reconsidered.

It's not surprising that very few people flipped the flag for Token Binding in about:flags and I don't believe it's a good indication of interest or adoption. There's no reason a regular browser user would know anything about Token Binding our why to enable it. In fact, I’d argue that it is a positive aspect of Token Binding that an end-user doesn’t need to know anything about it (in contrast to TLS client certificates) to benefit from the protections it can afford. The specifications have been in draft for the two year+ period mentioned and the support behind a flag has been extremely useful for development and interoperability testing. But the number of people doing that kind work on a draft standard is limited so it makes sense that there would be low usage numbers at this point. 

Removing support right as the specs are about to go RFC and without the feature ever having come out from behind a flag feels to me like it’s prematurely putting the nail in the coffin of an otherwise useful and promising standard.

There is real interest and excitement around Token Binding from the community that will be deploying and using it. As just one example, this tweet is from a recent digital identity conference presentation about Token Binding https://twitter.com/cmort/status/1011268388885270528 and shows the topic was very popular among IAM professionals. And there is a draft standards for SSO use-cases that make use of browser support of Token Binding - OpenID Connect Token Bound Authentication -  as well as OAuth use cases https://tools.ietf.org/html/draft-ietf-oauth-token-binding-07

Browser support is a huge and key part of adoption of the technology at large and I again ask/beg that the removal from Chrome be reconsidered.

Thank you

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

Ryan Sleevi

unread,
Aug 14, 2018, 5:21:30 PM8/14/18
to =JeffH, blink-dev, Nick Harper, net-dev, Dirk Balfanz, Andrei Popov, bcam...@pingidentity.com


On Tue, Aug 14, 2018 at 5:12 PM <jeff....@kingsmountain.com> wrote:
Quoting bcampbell via blink-dev <blin...@chromium.org>:
>
> I would like to respectfully ask (or maybe beg) that removal be
> reconsidered.

I agree with Brian (bcampbell) and request that token binding support 
not be removed, per Brian's rationale below.

Also, W3C WebAuthn has a dependency on token binding (TB) 
<https://www.w3.org/TR/webauthn/#dom-collectedclientdata-tokenbinding>.

That doesn't really seem to be a dependency. It fully acknowledges that clients may not support TB, which can be handled gracefully. Is that a misunderstanding of the 'dependency'? 

jeff....@kingsmountain.com

unread,
Aug 14, 2018, 5:50:29 PM8/14/18
to blink-dev, nha...@chromium.org, net...@chromium.org, bal...@google.com, Andrei...@microsoft.com, bcam...@pingidentity.com
Quoting bcampbell via blink-dev <blin...@chromium.org>:
>
> I would like to respectfully ask (or maybe beg) that removal be
> reconsidered.

I agree with Brian (bcampbell) and request that token binding support
not be removed, per Brian's rationale below.

Also, W3C WebAuthn has a dependency on token binding (TB)
<https://www.w3.org/TR/webauthn/#dom-collectedclientdata-tokenbinding>.

As Brian notes, the the TB specs are in the RFC editor queue:

https://datatracker.ietf.org/wg/tokbind/documents/

thanks for your consideration,

=JeffH


> It's not surprising that very few people flipped the flag for Token Binding
> in about:flags and I don't believe it's a good indication of interest or
> adoption. There's no reason a regular browser user would know anything
> about Token Binding our why to enable it. In fact, I’d argue that it is a
> positive aspect of Token Binding that an end-user doesn’t need to know
> anything about it (in contrast to TLS client certificates) to benefit from
> the protections it can afford. The specifications have been in draft for
> the two year+ period mentioned and the support behind a flag has been
> extremely useful for development and interoperability testing. But the
> number of people doing that kind work on a draft standard is limited so it
> makes sense that there would be low usage numbers at this point.
>
> Removing support right as the specs are about to go RFC and without the
> feature ever having come out from behind a flag feels to me like it’s
> prematurely putting the nail in the coffin of an otherwise useful and
> promising standard.
>
> There is real interest and excitement around Token Binding from the
> community that will be deploying and using it. As just one example, this
> tweet is from a recent digital identity conference presentation about Token
> Binding https://twitter.com/cmort/status/1011268388885270528 and shows the
> topic was very popular among IAM professionals. And there is a draft
> standards for SSO use-cases that make use of browser support of Token
> Binding - OpenID Connect Token Bound Authentication
> <https://openid.net/specs/openid-connect-token-bound-authentication-1_0.html>
> - as well as OAuth use cases
> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-07
>
> Browser support is a huge and key part of adoption of the technology at
> large and I again ask/beg that the removal from Chrome be reconsidered.
>
> Thank you
>
> On Wednesday, August 1, 2018 at 11:36:10 AM UTC-6, Nick Harper wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Primary eng (and PM) emailsnha...@chromium.org <javascript:>Links to
>> other Intents threadsIntent to Implement:
>> https://groups.google.com/a/chromium.org/d/topic/blink-dev/jTwWj2Y_IPM/discussion
>> <https://groups.google.com/a/chromium.org/d/topic/blink-dev/C-iuVJeDGkk/discussion>SummaryToken
>> Binding is a feature that has been behind a flag for over two years and has
>> never shipped. (No Intent to Ship for Token Binding ever got approved.) I
>> plan to remove all code related to this unused feature.MotivationAfter
>> weighing the security benefit of Token Binding against the engineering
>> costs, maintenance costs, web compatibility risk, and adoption, it does not
>> make sense to ship this feature.Interoperability and Compatibility
>> RiskThere is little risk to removing this feature. It has never been on by
>> default, and there has been little industry adoption. Edge is the only
>> other browser that supports Token Binding; Chrome will behave as any other
>> browser that does not support Token Binding.Edge: Supported, negative to
>> removalFirefox: not supportedSafari: not supportedAlternative
>> implementation suggestion for web developersDepending on the use case that
>> a site operator had for Token Binding, there are other technologies that
>> can be used. For protecting cookies against XSS, the HttpOnly flag can be
>> used. For providing a cryptographic assertion that both peers are on the
>> same connections, TLS client certificates can be used. Some use cases might
>> be able to use WebCrypto.Usage information from UseCounter
>> <https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>No
>> information from UseCounter. Based on the Net.TokenBinding.Support UMA
>> histogram, less than 00.01% of HTTPS requests on Stable had Token Binding
>> attempted. This indicates that very few people flipped the flag in
>> about:flags for Token Binding.Entry on the feature dashboard
>> <https://www.chromestatus.com/>https://www.chromestatus.com/feature/5097603234529280
>> <https://www.chromestatus.com/feature/5097603234529280>*
>>
>>


Nick Harper

unread,
Aug 14, 2018, 7:10:07 PM8/14/18
to Ryan Sleevi, =JeffH, blink-dev, net-dev, Dirk Balfanz, Andrei Popov, Brian Campbell
I agree that the number of people flipping a flag in about:flags is a poor measure of interest or adoption. (It was mentioned in the email to estimate potential breakage.) However, for most features that we implement in Chrome, there are lots of third parties coming to us wanting to use the new features, which is something I've seen very little of with Token Binding.

Adoption was only one part of the decision to not ship Token Binding. The primary motivators were the little perceived security benefit of Token Binding, the large expected ongoing maintenance and support costs, and concerns around web compatibility risks.

Evaluating Token Binding's security benefits involved considering how tokens might get stolen (since it's stated goal is to prevent token theft). Client malware seems to be the most-often cited example in Token Binding discussions, yet this is outside the scope of Chrome's threat model. The most likely relevant scenarios for token theft within Chrome's threat model are XSS and rogue extensions. For XSS, we have other better tools than Token Binding. Rogue extensions is an interesting issue that gets into broader interactions between Token Binding and the web platform.

Users of the web platform (for better or worse) expect cookies (and other credentials) to be bearer tokens. This is reflected in Apps and Extensions APIs that expose cookies and OAuth tokens, as well as in developer tools. A successful launch of Token Binding would need to address how Apps and Extensions would be able to use bound tokens to avoid breaking existing legitimate use cases. This requires extensive work both to the Extensions platform and for the Extension authors. A rogue extension would also be able to make use of the modified APIs to continue to exercise the tokens it would have stolen, meaning that in all likelihood the problem of token theft via rogue extensions isn't best solved by Token Binding, but by some other change to the extension ecosystem. Developer tools also break with Token Binding, for example "Copy as cURL" and intercepting proxies (e.g. Fiddler, Charles Proxy).

--
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/CACvaWvYPJuxpUumqp7OHxyeTiCATUsn6g202Mnu1rXNK0BuQuQ%40mail.gmail.com.

dwa...@pingidentity.com

unread,
Aug 15, 2018, 1:17:48 PM8/15/18
to blink-dev, rsl...@chromium.org, jeff....@kingsmountain.com, net...@chromium.org, bal...@google.com, Andrei...@microsoft.com, bcam...@pingidentity.com


On Tuesday, August 14, 2018 at 5:10:07 PM UTC-6, Nick Harper wrote:
[snip]

Evaluating Token Binding's security benefits involved considering how tokens might get stolen (since it's stated goal is to prevent token theft). Client malware seems to be the most-often cited example in Token Binding discussions, yet this is outside the scope of Chrome's threat model. The most likely relevant scenarios for token theft within Chrome's threat model are XSS and rogue extensions. For XSS, we have other better tools than Token Binding. Rogue extensions is an interesting issue that gets into broader interactions between Token Binding and the web platform.

A valuable purpose of token binding is that it provides proof of possession of cookies and (perhaps more importantly) access tokens. A cookie is typically considered homogenous state (which may represent authentication and access) for a domain, but tokens are often used in a more heterogenous manner. It is incredibly useful to have a way to know that an API request came from the client, and not from some other (possibly compromised) API endpoint that accepts the same token.

Token binding provides little value to the browser and is transparent to the user, but does provide increased security that isn't comparably available otherwise.

From your original message:

For providing a cryptographic assertion that both peers are on the same connections, TLS client certificates can be used. Some use cases might be able to use WebCrypto.

Neither one of these is an acceptable substitute, because neither can be transparently applied to a TLS connection. The TLS client certificate loading process is very technical and user intensive, leaks information (because the certificates are not origin-scoped), and has a different process in each browser. The only common browser functionality to automate this was the now-removed <keygen> element.

CryptoAPI provides an ability to generate keys, but there is no way to apply these at the connection level either. Integrity and confidentiality protections are entirely the scope of custom developer code which will need to be adopted to the each application protocol (such as API traffic over HTTP vs API traffic over web sockets). Otherwise securing non-application traffic would AFAIK require service workers, which would again be emitting non-standardized data.

It is possible that new specifications building on Crypto API might be used to generate and register per-origin client certificates, but AFAIK no spec work around something like this has been started. This would also still not be as transparent as token binding, requiring at a minimum a service worker to request/maintain that client certificate. This would also substantially increase initial latency for loading a site attempting to secure its credentials with such functionality.

Users of the web platform (for better or worse) expect cookies (and other credentials) to be bearer tokens. This is reflected in Apps and Extensions APIs that expose cookies and OAuth tokens, as well as in developer tools. A successful launch of Token Binding would need to address how Apps and Extensions would be able to use bound tokens to avoid breaking existing legitimate use cases.

As application code should have a fallback for when token binding is not available on a platform, these cases seem solvable to the developer-user of the web platform by either:
1. Not requesting token binding on their web properties
2. Disabling token binding for the origin of their web properties during development/debugging

This requires extensive work both to the Extensions platform and for the Extension authors. A rogue extension would also be able to make use of the modified APIs to continue to exercise the tokens it would have stolen, meaning that in all likelihood the problem of token theft via rogue extensions isn't best solved by Token Binding, but by some other change to the extension ecosystem.

I'm not familiar with the changes that would be necessary for the extension platform as I would expect it to use the same token binding; does it use a different connection pool?

Agreed that token binding is not a silver bullet as long as browsers allow arbitrary code to execute against any web property, but this seems like an independent, fundamental design issue with extensions and their security model. An end-user is simply not qualified to understand the ramifications of allowing an extension to introspect and monkey-patch their web traffic, and web properties do not opt-in to extension access based on their own evaluation of trust (like they do with say CORS.)
 
Developer tools also break with Token Binding, for example "Copy as cURL" and intercepting proxies (e.g. Fiddler, Charles Proxy).

Is this not easily solvable by temporarily disabling token binding? 

This may change underlying behavior of an application (such as requiring authentication more often), but for development/debugging there are workarounds for that (such as an additional header in development to skip token binding validation when processing cookies/access tokens) 

Note that the replacement solutions proposed (CryptoAPI, Client TLS certificate) would *not* provide the opportunity of a developer tools-level flag to disable them, and would also not necessitate web properties having a consistent fall-back should they not be available.

Nick Harper

unread,
Aug 15, 2018, 5:25:30 PM8/15/18
to dwa...@pingidentity.com, blink-dev, Ryan Sleevi, =JeffH, net-dev, Dirk Balfanz, Andrei Popov, Brian Campbell
On Wed, Aug 15, 2018 at 9:24 AM, dwaite via net-dev <net...@chromium.org> wrote:
A valuable purpose of token binding is that it provides proof of possession of cookies and (perhaps more importantly) access tokens. A cookie is typically considered homogenous state (which may represent authentication and access) for a domain, but tokens are often used in a more heterogenous manner. It is incredibly useful to have a way to know that an API request came from the client, and not from some other (possibly compromised) API endpoint that accepts the same token.


I'm a bit confused by the scenario described here. The description of a compromised endpoint sounds like there's some handler for api.example.com/foo that is compromised, and makes a request to api.example.com/bar on the same server. However, if the compromised endpoint is on the same server as the endpoint it's sending a fake request to, how does Token Binding provide any benefit there? The compromised endpoint could call the same code as the other endpoint on the same server and skip any checks of the Token Binding signature. I think a more reasonable interpretation would be a scenario where api1.example.com and api2.example.com (two separate servers) both accept the same token, api1 gets compromised, and uses tokens it receives to make calls to api2. In this case, I think a better approach would be to have separate tokens used for api1 and api2, so one service can't use tokens it receives with another service. (One could imagine a 3rd endpoint, tgs.example.com, that takes a token-granting-token and can create a token valid for api1 or api2, so the client only has to deal with authenticating once to get the TGT, and then exchange the TGT for service-specific tokens as needed.)

Another scenario I've heard described where Token Binding helps protect against server-side theft is one where there are multiple applications sharing authentication cookies being served through a single reverse proxy. The reverse proxy terminates TLS and forwards to the application the Token Binding ID (assuming TB was used and the signature verifies). If one of the application servers gets compromised, it could take a cookie (that is not bound), and send it through the reverse proxy to another application and authenticate as a user, whereas if the cookie is bound, it won't be able to forge a Token Binding header when sending it to the reverse proxy. However, again, this problem can be solved without Token Binding. The authentication structure used by the multiple applications and the reverse proxy could be set up so that the reverse proxy converts the authentication cookie into some other token that can only be accepted by a single application, so that if a compromised application server tries to send it through the reverse proxy to another application, it won't be accepted. This cookie-to-token conversion would need to be done in some irreversible fashion so the cookie can't be recreated from the token.

It seems to me like protecting against server-side theft of tokens can be done server-side with other mechanisms than Token Binding. Additionally, by doing a server-side mitigation, it protects all users, not just users whose clients support Token Binding.

hans.z...@zmartzone.eu

unread,
Aug 15, 2018, 7:26:28 PM8/15/18
to blink-dev, rsl...@chromium.org, jeff....@kingsmountain.com, net...@chromium.org, bal...@google.com, Andrei...@microsoft.com, bcam...@pingidentity.com
+1 to DW's arguments, especially wrt. the security model of extensions; let's fix the latter instead of dropping support for token binding in browsers

there are many use cases where token bound cookies do offer increased security OOTB (as an example: think of enterprise environments where extensions are blocked/limited) but moreover: binding tokens to the communication channel is a good (optional) generic mechanism that supersedes specialized mechanisms like the ones to XSS attacks etc.; yes, there are a number of exceptions to that rule but let's not make those exceptions block adoption of a good generic security mechanism

Hans.

bcam...@pingidentity.com

unread,
Aug 17, 2018, 4:39:49 PM8/17/18
to blink-dev, rsl...@chromium.org, jeff....@kingsmountain.com, net...@chromium.org, bal...@google.com, Andrei...@microsoft.com, bcam...@pingidentity.com
For whatever it's worth, we (my employer) have had a lot of customer interest expressed in Token Binding, from those that even know what it is. As well as a lot of more general customer interest, from those that aren't even aware of Token Binding, in the kind of proof-of-possession protections that it can afford. We build SSO and access management server systems, which are dependent on browser support of standards. Personally, I never thought to come to you all wanting to use Token Binding because it was already there and I assumed that, given the active participation and leadership on the IETF standards, that it would come out from behind the flag after the drafts went to RFC. So please consider this, late as it might be, my asking for the feature and doing so on behalf of a lot of large enterprises.

There are other scenarios for token theft, which may not fall directly into Chrome's threat model but are relevant to web usage in general. Subdomain takeovers on a site that uses a widely (ETLD+1) scoped cookie for an authenticated session, for example, which happened to Uber last year. And we've seen scenarios where a domain scoped SSO cookie is issued from a centralized authentication service but the various individual applications on subdomains (or really the app owners) can't or shouldn't be trusted not to replay the cookie against other apps to impersonate the end user. Of course Token Binding isn't the only way to protect against these kinds of things but it offers a unique protection by allowing tokens/cookies to be inoculated against reply when stolen rather than attempting to prevent the theft in the first place. The latter is still important but token binding would open up new protections and possibilities that weren't practically achievable previously. There are also attacks on authorization and authentication protocols (OAuth, OpenID Connect, SAML) that use cross-domain redirection, which can be helped to mitigate by a proof-of-possession binding.

True, things like "Copy as cURL" and intercepting proxies won't work with token binding. I don't mean to downplay the impact of that but it's sort of fundamental given how token binding works. Bound tokens can't be used without the associated key. Sometimes things break in the name of advancing security at large. Look at TLS 1.3 and so called SSL interception no longer being possible with the removal of static RSA.

I realize I'm somewhat biased here because I've invested a lot personally into and around Token Binding*. But I did so because I really believe it has (or had anyway) the potential to significantly benefit the security of the web as a whole. Without browser support, however, it's likely dead in the water.


* for example:


On Tuesday, August 14, 2018 at 5:10:07 PM UTC-6, Nick Harper wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.

To post to this group, send email to net...@chromium.org.

Devdatta Akhawe

unread,
Aug 17, 2018, 5:55:40 PM8/17/18
to blink-dev, rsl...@chromium.org, jeff....@kingsmountain.com, net...@chromium.org, bal...@google.com, Andrei...@microsoft.com, bcam...@pingidentity.com
Adding a bit of support: we were also looking at adopting token binding too. As Brian notes, it provides a bunch of interesting security properties that are hard to get in any other mechanism. 

ve7...@ve7jtb.com

unread,
Aug 19, 2018, 5:12:49 PM8/19/18
to blink-dev
Adding to Jeff's comments, Google Microsoft and many others have been contributing to the Fido and W3C webAuthentication standards that have a dependency on Token Binding.

They do for a good reason. In order to meet SP800-63-3 requirements for AAL3 authentication the Fido token MUST be cryptogtaphicly bound to the access channel. (I know it says shall in the standard but it is a synonim for must in IETF and NIST specifications, arguing won't change that).

Removing token binding from chrome will force people to continue using smart cards or use a browser that supports Token Binding.

Perhaps cookies can be protected other ways, I will grant you that. Although I have some reservations on that as well.

On cross origin redirects for OpenID Connect, SAML and OAuth Token Binding is the only real option. That also applies to protecting WebAuthn from MIM attacks.

I agree with Brian that people haven't been hounding you to impliment token binding because based on statements by senior people at Google and the fact that you developed it and brought it to the IETF, people believed that you were committed to it.

Token Binding will continue without Chrome if it needs to, but it will be unfortunate.

Regards
John Bradley. Yubico

independe...@gmail.com

unread,
Aug 19, 2018, 5:13:19 PM8/19/18
to blink-dev
FWIW my org was also considering adoption once RFC. There is strong demand for PoP tokens and cookies and TokBind is the leading solution. Bearer tokens have costs and risks that many customers are expressing concerns over.

This comes as a surprise given Google’s particupation and leadership on this effort and the lateness of its withdrawl as the RFCs are about to be published.

Phil

gffl...@aol.com

unread,
Aug 19, 2018, 5:13:34 PM8/19/18
to blink-dev
I too am very interested in Token Binding and am actively considering implementation. I believe the security properties are valuable on the server side to easily detect token hijacking and replay.

To be quite honest I’m surprised that the Beyond Corp effort is not actively pursuing Token Binding as it provides a strong assurance regarding the incoming connection from the browser.

Thanks,
George

Tom Jones

unread,
Aug 20, 2018, 2:26:40 PM8/20/18
to blink-dev
is there any documentation anywhere that describes why channel binding is better that device binding? I was there when channel binding was first invented and never was able to determine why there weren't better solutions.

jfon...@yubico.com

unread,
Aug 20, 2018, 6:09:12 PM8/20/18
to blink-dev
+1 with John Bradley. So much good work is coming to fruition now and signaling the importance Token Binding.  Pulling the rug out is a major setback.  

rek...@gmail.com

unread,
Aug 21, 2018, 5:41:34 PM8/21/18
to blink-dev, net...@chromium.org
Joining the "please no" crew.

Token Binding seems like it has significant potential to help web developers more easily, securely do user sign in & SSO scenarios (talked about some in https://www.slideshare.net/briandavidcampbell/token-binding#15). It doesn't seem like this feature was given a genuine test, which is unfortunate. Not implementing this feature seems like it risks pushing a lot more complexity/checks back to web programmers, whereas implementing this standard brings a reliable, known way to get some really good additional assurances about one's bearer tokens.

I'm particularly excited about the potential for bearer tokens to reduce the complexity of SSO flows, but it seems like there's a total package of great, sensible security mechanisms here.

ad...@fidoalliance.org

unread,
Aug 21, 2018, 10:12:46 PM8/21/18
to blink-dev
In addition to the other WebAuthn points, I would mention that Token Binding isn't an "optional feature" of WebAuthn but it was considered as a "necessary feature that doesn't have broad enough adoption yet". WebAuthn is dependent on origin for anti-phishing, and in cases where origin could be spoofed (e.g. - DNS hijacking) token binding was considered as a further countermeasure. Many of the conversations in WebAuthn / FIDO working groups ended with "...and that is something that will be solved by Token Binding" -- it's not clear at this point whether all those instances have other options or not, or how much churn this would cause for WebAuthn or other technologies that have been anticipating Token Binding.

Anne van Kesteren

unread,
Aug 22, 2018, 2:56:47 AM8/22/18
to ad...@fidoalliance.org, blink-dev
On Wed, Aug 22, 2018 at 4:12 AM <ad...@fidoalliance.org> wrote:
> where origin could be spoofed (e.g. - DNS hijacking)

How would that work given that WebAuthn requires secure contexts (i.e., HTTPS)?


--
https://annevankesteren.nl/

jon.le...@gmail.com

unread,
Aug 22, 2018, 8:49:23 PM8/22/18
to blink-dev, net...@chromium.org
Hi,

From the enterprise practitioner's perspective, I respectfully ask you keep token binding in Chrome.

RESTful security services and a robust/secure API ecosystem are two key factors in enterprise digital transformation initiatives. I've championed the adoption of OAuth/OIDC to facilitate this transformation at two large enterprises. A legitimate point of contention from the security architecture teams I've worked with have come from the risk of token theft through the use of bearer tokens. For two years architects like me have been waiting for Token Binding to get ratified so we would have a transparent mechanism to close this gap. If this gets dropped from Chrome, this enterprise use case doesn't go away- it will just necessitate the switch to browsers which will support it. It will be like going back to the times when every workstation had to include IE7 for some crusty, old, mission critical application, only now we need to use Edge because our enterprise auth server won't deal in unbound tokens. And I haven't even touched on the plans we have for WebAuthN, and how this move would impact Chrome's footing as we move toward its broad adoption.

Dropping support now that Token Binding would be an unforced error IMO.

Thanks,
Jon Lehtinen

rlind...@noknok.com

unread,
Aug 24, 2018, 6:01:11 PM8/24/18
to blink-dev, net...@chromium.org
I would vote for keeping token binding support in Chrome and even make it available by default (i.e. without a flag).  It helps substantially protecting against real-time MITM attacks.

Peter Huang

unread,
Aug 24, 2018, 6:01:11 PM8/24/18
to blink-dev, net...@chromium.org
I'm from a security team which maintain the standard and policy and we have been waiting to get token binding deploy ever since middle last year.  It is a major step forward to protect bearer token as secure cookie isn't enough (many attempts with secure cookie in the past).  in my view, if chrome remove it, then we will revise our standard to move away from chrome browser and leverage one that use token binding. 

jeff.cor...@gmail.com

unread,
Aug 24, 2018, 6:01:11 PM8/24/18
to blink-dev, net...@chromium.org
My organization is also working on adoption of token binding with openid connect

Please don't remove token binding support from chrome. 

Thank you,

-Jeff Corrigan

gokhan...@gmail.com

unread,
Aug 24, 2018, 6:01:11 PM8/24/18
to blink-dev
Both WebAuthn and token binding is collaborative effort of several companies under W3C WGs. It's great to see experts of competitor companies working together to form these standards . This is because we all are in same boat. This work is for security of the internet.
However competition should be about how quickly to adopt these new and better standards . Google was ahead of competition with implementation. Why to go backwards instead of fully supporting what has already been implemented.

Phil

unread,
Aug 24, 2018, 6:01:11 PM8/24/18
to blink-dev, net...@chromium.org, Phil Whipps
I totally agree with Brian Campbell, why would you do this?

With the adoption of Token Binding for OIDC / OAuth2 in initiatives like Open Banking etc, if you have an even more secure authentication mechanism why would Chrome not want to be a part of that ? 

lpet...@gmail.com

unread,
Aug 24, 2018, 6:01:11 PM8/24/18
to blink-dev, net...@chromium.org
Adding another enterprise practitioner's perspective. My thoughts closely echo Jon L.'s. PoP has long been a gap in OAuth's functionality and we had been waiting for TB to go RFC before pushing for adoption internally. Some of this is deliberate to couple the change with WebAuthn because of the dependencies involved. I would encourage you to keep it behind the flag for now, and give us a 2nd choice for token binding that isn't bound to a single OS platform.

Respectfully,

Lance Peterman
Merck

nyny...@gmail.com

unread,
Aug 29, 2018, 3:14:39 PM8/29/18
to blink-dev, net...@chromium.org
Gluu plans to support token binding in Gluu Server 4.0, which should be available Jan '19. I think you just need to give it more time. Protecting against MITM attacks is a worthy goal, and if the investment to keep the feature is small, I think it's worth it. Please reconsider.

Mike Schwartz
CEO Gluu

forest...@gmail.com

unread,
Aug 29, 2018, 9:16:47 PM8/29/18
to blink-dev
Token binding is one of measures to prevent OIDC / OAuth 2 from MITM attackers. (can't prevent crypting.)
It is the only means of defense in implementation using a separate Resource Server.

WebAuthAPI will become more popular in the next few years.
As a result, this function will be used more frequently.

Remove this function now will carry more risks(Confidentiality).

Ryan Hamilton

unread,
Aug 31, 2018, 10:03:45 AM8/31/18
to c79...@gmail.com, blink-dev, net-dev

On Thu, Aug 30, 2018 at 11:53 PM, <c79...@gmail.com> wrote:
Token Binding is primarily a standardised version of Chrome's Channel ID feature.

Channel ID has not been behind a flag.
Looking at my "all cookies and site data" shows dozens and dozens of sites (many related to Google) are using Channel ID.

Is Channel ID also going to be switched off?
If Google's multi-year multi-site experience with Channel ID hadn't shown any security benefit then removing Token Binding would be understandable, but I haven't seen anyone state that.

--
James Manger

--
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.

c79...@gmail.com

unread,
Sep 2, 2018, 7:04:46 PM9/2/18
to blink-dev, net...@chromium.org

wden...@google.com

unread,
Oct 18, 2018, 8:10:03 PM10/18/18
to blink-dev
The IETF specifications related to this feature were published this month as RFC 8471, RFC 8472, and RFC 8473, signaling consensus in the standards community for how to approach the problem of bearer tokens at this layer.

I'd love to see this option remain in Chrome a while longer so there's a chance to see if this recent protocol standardization leads to greater adoption.

Fergal Daly

unread,
Oct 18, 2018, 9:19:25 PM10/18/18
to r...@chromium.org, c79...@gmail.com, blin...@chromium.org, net...@chromium.org
And the motivation for removing includes that it is obsoleted by Token Binding which in that thread is confirmed to fix a bunch of problems with Channel ID.

The LGTMs for Channel ID removal specifically reference Token Binding. Do those LGTMs stand if Token Binding is also going away?

F



Cheers,

Ryan

On Thu, Aug 30, 2018 at 11:53 PM, <c79...@gmail.com> wrote:
Token Binding is primarily a standardised version of Chrome's Channel ID feature.

Channel ID has not been behind a flag.
Looking at my "all cookies and site data" shows dozens and dozens of sites (many related to Google) are using Channel ID.

Is Channel ID also going to be switched off?
If Google's multi-year multi-site experience with Channel ID hadn't shown any security benefit then removing Token Binding would be understandable, but I haven't seen anyone state that.

--
James Manger

--
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+u...@chromium.org.

To post to this group, send email to net...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ_4DfREGvbmFHSe%3D9tEC_jgkob6zTyhfK76PYCKJF78nCYgYA%40mail.gmail.com.
Message has been deleted

fredlet...@gmail.com

unread,
Oct 23, 2018, 7:07:38 PM10/23/18
to blink-dev
[Edited/reposted]
Please no, fu*k no.

Token binding is the only secure way to fight against several kinds of MITM attacks.
Token binding support is now implemented or currently beeing implemented on several server side solutions
Token binding is going through the final IETF stage
Token binding is already supported by Edge
Firefox team refused to work on channel ID binding because they were waiting for token Binding to ne finalized to work on it instead
FIDO2 (WebAuthn/w3c) anti-mitm part is based on token binding
OpenID EAC references token binding...

See the hopes inside the previous comments...

Why the hell I am reading now that token binding support is being considered to be removed from Chrome ???????????? Just when many solution providers, at last, agree it is the only reliable anti-mitm solution that is currently being adopted as a standard ?

Can someone PLEASE confirm this mad idea to remove token binding support from Chrome has been reconsidered?

Pleeeeaaaaaasssse ? * sigh *

fredlet...@gmail.com

unread,
Nov 12, 2018, 9:33:41 AM11/12/18
to blink-dev

RECENT FINAL UPDATE AS NOVEMBER 12TH, 2018:

TOKEN BINDING SUPPORT HAVE BEEN REMOVED FROM CHROME.

That's a pity, it makes no sens but it is true.

--
Fred

Tom Jones

unread,
Nov 13, 2018, 7:31:13 PM11/13/18
to fredlet...@gmail.com, blin...@chromium.org
I believe it makes perfect sense. Here is a paper that i wrote to support the inadequacy of Bearer tokens and token binding.   https://tcwiki.azurewebsites.net/index.php?title=Bearer_Tokens_Considered_Harmful#Introduction

Peace ..tom


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3b19d253-c2da-403b-b72e-bb615976100a%40chromium.org.

Fred Le Tamanoir

unread,
Nov 25, 2018, 3:29:06 PM11/25/18
to thomascli...@gmail.com, blin...@chromium.org
AFAIK, your paper did not say that Token Binding is not technically effective against MITM but is "just" about the limitation regarding the presented server identity and the Entity behind it. 
It may be a valid point but is completely not the subject here.
You can even be your own CA if you want... you should be able to use Token Binding. 

So it stil does not make any sense and I still do not understand how the people behind Token binding an be so silent about this stupid decision.

Frank

unread,
May 8, 2020, 12:14:51 PM5/8/20
to blink-dev, net...@chromium.org
1.5 years passed since the this topic was discussed, are there now clearer direction on where is token binding going on chrom?Being an enterprise security practionner, I do believe the security benefit of token binding and hope the industry can reach consensus about its adoption.

Tom Jones

unread,
May 8, 2020, 12:28:08 PM5/8/20
to Frank, blink-dev, net...@chromium.org
token binding, and earlier channel binding, are flawed security ideas. The basic idea seems to be that since we are not competent to create security at the application layer, we will hitchhike on security at lower layers in the communication stack. This looks attractive for a while but breaks down as the complexity of the application needs outstrips the capability of binding at the lower layer, which never maps well to the user or the legal entity that is behind the web site. Let this dog lay sleeping. It is never fun to try to enable complex applications with simplistic security solutions.
Peace ..tom


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

dwa...@pingidentity.com

unread,
May 8, 2020, 1:33:21 PM5/8/20
to blink-dev, stdf...@gmail.com, net...@chromium.org
This is not industry consensus.

We have big gaps at the application layer - sites must actively take steps to prevent script injection, and can't control script injection by browser extensions. This does not disguise that the browser does not enable proof of possession, nor does it offer any mechanism to prevent exfiltration of security tokens. Token leakage by compromised parties, token reuse by malicious parties, and token exfiltration by javascript are real world attacks.
 
In OAuth we are trying to work around these limitations partially with DPoP, but it is inferior approach to both MTLS and token binding approaches. It is simply the best that browsers can offer with the poor MTLS UX and with removed support for the Token Binding RFC.

Implementers and deployers are upset because this is a real world issue, and we thought that token binding was on track to become a proper solution. We were blindsided by the removal, with no effort extended to try to solve our problems in any other way.

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

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

Hans Zandbelt

unread,
May 8, 2020, 1:35:34 PM5/8/20
to David Waite, blink-dev, stdf...@gmail.com, net...@chromium.org
Can we also get rid of TLS while we're at it please? It is very annoying and we can solve it better at the application level... :-\

Hans.

You received this message because you are subscribed to a topic in the Google Groups "net-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/net-dev/8QD01FloF1o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/12d14b1f-e825-4b7e-ad32-d0f4787e3548%40chromium.org.

Tom Jones

unread,
May 8, 2020, 2:00:38 PM5/8/20
to dwa...@pingidentity.com, blink-dev, stdf...@gmail.com, net...@chromium.org
Sorry, but i am more interested in real security that can work in real-world situations than consensus.  Face it, token binding and channel bindings are hacks.
Peace ..tom


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/12d14b1f-e825-4b7e-ad32-d0f4787e3548%40chromium.org.
Reply all
Reply to author
Forward
0 new messages