Intent to Remove: Token Binding

[Nick Harper]

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]

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]

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]

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]

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/jTwWj2Y_IPM/discussion>Intent
>> to Ship (take 1):
>> https://groups.google.com/a/chromium.org/d/topic/blink-dev/r4zE8RKB6l4/discussion
>> <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

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

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]

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]

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]

+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]

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:

https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-06

https://openid.net/specs/openid-connect-token-bound-authentication-1_0.html

https://tools.ietf.org/html/draft-ietf-oauth-token-binding-07

https://github.com/pingidentity/java8-token-binding-negotiation (also for 9 and 10)

https://github.com/pingidentity/token-binding-java

https://www.slideshare.net/briandavidcampbell/token-binding-identiverse-2018

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACvaWvYPJuxpUumqp7OHxyeTiCATUsn6g202Mnu1rXNK0BuQuQ%40mail.gmail.com.

[Devdatta Akhawe]

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]

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]

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]

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]

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]

+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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

https://gluu.org

[forest...@gmail.com]

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]

Channel ID is indeed being removed:

https://groups.google.com/a/chromium.org/forum/?utm_medium=email&utm_source=footer#!msg/net-dev/AjFQjBmaEQE/_3DM1hwGCQAJ

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+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/aae298e0-29ff-42c5-980e-7d0ef97ebc51%40chromium.org.

[c79...@gmail.com]

[wden...@google.com]

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]

On Fri, 31 Aug 2018 at 23:03, Ryan Hamilton <r...@chromium.org> wrote:

Channel ID is indeed being removed:

https://groups.google.com/a/chromium.org/forum/?utm_medium=email&utm_source=footer#!msg/net-dev/AjFQjBmaEQE/_3DM1hwGCQAJ

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/aae298e0-29ff-42c5-980e-7d0ef97ebc51%40chromium.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.

[fredlet...@gmail.com]

[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]

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