Intent to Deprecate and Remove: Channel ID

[Nick Harper]

Primary eng (and PM) emails
nha...@chromium.org

Summary
Channel ID is a network feature where on each TLS connection to a server that supports Channel ID, the client proves possession of a private key, allowing the server to bind credentials to the Channel ID key, accepting them only when the Channel ID is also provided. Once a Channel ID is created for a site, Chrome does not change that Channel ID (unless the user clears cookies/browsing data for that site); Chrome uses a separate Channel ID for each eTLD+1.

A detailed technical plan for its removal is described at https://docs.google.com/document/d/1phCknRCnrad7M4cgGusLpKz5A1lLzq0oShahlMgY29Q/edit.

Motivation
Channel ID was never standardized, and has only been implemented by Google. Attempts at standardization lead to Token Binding, covered in a separate Intent to Ship (https://groups.google.com/a/chromium.org/d/msg/blink-dev/C-iuVJeDGkk/IfIam8_rFgAJ).

The design of Channel ID imposes multiple burdens and limitations on the network stack. Channel ID’s proof of possession is done once at the beginning of the TLS handshake, instead of provided on each HTTP request. This connection-based authentication (instead of request-based authentication) leads to added complexity in the implementation. The introduction of Channel ID resulted in splitting socket pools in two, having “privacy mode” (without Channel ID) and non privacy mode (with Channel ID) socket pools because of the ambient authentication carried from per-connection instead of per-request authentication. Channel ID also requires us to tear down connections when users delete browsing data. Channel ID prevents HTTP/2 connection coalescing across multiple domains (e.g. google.com and youtube.com). Channel ID is incompatible with the 0-RTT mode of TLS 1.3.

Interoperability and Compatibility Risk
Chrome is the only UA that implements Channel ID. Google’s servers are the only known servers to implement the feature, and they have no known behavior that requires Channel ID (such behavior would require Chrome to be the UA). There is little interoperability risk to removing Channel ID.

There is some compatibility risk to the removal of Channel ID. Since a server may choose to bind cookies to the Channel ID, when Channel ID is removed the server may have a one-time rejection of cookies. Once the server rejects and reissues cookies (or updates server-side session state to indicate there is no more Channel ID binding), the removal of Channel ID causes no more problems; the server behaves the same as any other browser that never supported Channel ID.

Edge: not supported
Firefox: not supported
Safari: not supported

Alternative implementation suggestion for web developers
A combination of WebCrypto and Service Workers may be able to provide similar functionality, depending on the server’s use case. Token Binding is intended as a direct replacement for Channel ID, which may be available in the future. TLS client certificates could also be used.

Usage information from UseCounter
No usage information from UseCounter. The only known servers to use Channel ID are Google servers. Removal will result in falling back to behavior used for other browsers; users should not notice this change.

Requesting approval to remove too?
Yes

[Nick Harper]

Re-sending to blink-dev

[Yoav Weiss]

On Fri, Mar 30, 2018 at 11:26 PM Nick Harper <nha...@chromium.org> wrote:

Re-sending to blink-dev

On Fri, Mar 30, 2018 at 2:14 PM, Nick Harper <nha...@chromium.org> wrote:

Primary eng (and PM) emails
nha...@chromium.org

Summary
Channel ID is a network feature where on each TLS connection to a server that supports Channel ID, the client proves possession of a private key, allowing the server to bind credentials to the Channel ID key, accepting them only when the Channel ID is also provided. Once a Channel ID is created for a site, Chrome does not change that Channel ID (unless the user clears cookies/browsing data for that site); Chrome uses a separate Channel ID for each eTLD+1.

A detailed technical plan for its removal is described at https://docs.google.com/document/d/1phCknRCnrad7M4cgGusLpKz5A1lLzq0oShahlMgY29Q/edit.

That plan seems to put the feature behind a flag rather than remove its code, and states that it will initially disable it only in TLS-1.3 0-RTT scenarios. Is that still the plan? Or are you planning to remove/disable it in all scenarios?

 

Motivation
Channel ID was never standardized, and has only been implemented by Google. Attempts at standardization lead to Token Binding, covered in a separate Intent to Ship (https://groups.google.com/a/chromium.org/d/msg/blink-dev/C-iuVJeDGkk/IfIam8_rFgAJ).

Is there progress on that intent? Not that it's a blocker, but would be good to see progress on that front.

 

The design of Channel ID imposes multiple burdens and limitations on the network stack. Channel ID’s proof of possession is done once at the beginning of the TLS handshake, instead of provided on each HTTP request. This connection-based authentication (instead of request-based authentication) leads to added complexity in the implementation. The introduction of Channel ID resulted in splitting socket pools in two, having “privacy mode” (without Channel ID) and non privacy mode (with Channel ID) socket pools because of the ambient authentication carried from per-connection instead of per-request authentication. Channel ID also requires us to tear down connections when users delete browsing data. Channel ID prevents HTTP/2 connection coalescing across multiple domains (e.g. google.com and youtube.com). Channel ID is incompatible with the 0-RTT mode of TLS 1.3.

That's a long list of serious limitations, so would be happy to see that resolved.

Does Token Binding get rid of all these limitations?

 

Interoperability and Compatibility Risk
Chrome is the only UA that implements Channel ID. Google’s servers are the only known servers to implement the feature, and they have no known behavior that requires Channel ID (such behavior would require Chrome to be the UA). There is little interoperability risk to removing Channel ID.

There is some compatibility risk to the removal of Channel ID. Since a server may choose to bind cookies to the Channel ID, when Channel ID is removed the server may have a one-time rejection of cookies. Once the server rejects and reissues cookies (or updates server-side session state to indicate there is no more Channel ID binding), the removal of Channel ID causes no more problems; the server behaves the same as any other browser that never supported Channel ID.

Edge: not supported
Firefox: not supported
Safari: not supported

Alternative implementation suggestion for web developers
A combination of WebCrypto and Service Workers may be able to provide similar functionality, depending on the server’s use case. Token Binding is intended as a direct replacement for Channel ID, which may be available in the future. TLS client certificates could also be used.

Usage information from UseCounter
No usage information from UseCounter. The only known servers to use Channel ID are Google servers. Removal will result in falling back to behavior used for other browsers; users should not notice this change.

Requesting approval to remove too?
Yes

--
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/CACdeXi%2B0%2B4J-inzCO4oU%2B_iZZvXF2FG%2BYjSoqs6z-0pc6%3DyR6Q%40mail.gmail.com.

[Matt Menke]

So does this means we'll be getting rid of the privacy mode socket pools, and mixing sockets with and without cookies and connection-based auth once again?

--
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/CACdeXi%2BVVAoFUyh5%2BYCECHL8UxuzTngioNOzhQvcpUyZTfzpXA%40mail.gmail.com.

[Ryan Sleevi]

On Tue, Apr 3, 2018 at 7:50 AM, Matt Menke <mme...@chromium.org> wrote:

So does this means we'll be getting rid of the privacy mode socket pools, and mixing sockets with and without cookies and connection-based auth once again?

The current behaviour is part of the Fetch spec, and independent of this intent. This intent would allow for exploring that change, but that chance was also made for privacy reasons, not purely related to Channel ID. 

[Nick Harper]

On Tue, Apr 3, 2018 at 1:39 AM, Yoav Weiss <yo...@yoav.ws> wrote:

On Fri, Mar 30, 2018 at 11:26 PM Nick Harper <nha...@chromium.org> wrote:

Re-sending to blink-dev

On Fri, Mar 30, 2018 at 2:14 PM, Nick Harper <nha...@chromium.org> wrote:

Primary eng (and PM) emails
nha...@chromium.org

Summary
Channel ID is a network feature where on each TLS connection to a server that supports Channel ID, the client proves possession of a private key, allowing the server to bind credentials to the Channel ID key, accepting them only when the Channel ID is also provided. Once a Channel ID is created for a site, Chrome does not change that Channel ID (unless the user clears cookies/browsing data for that site); Chrome uses a separate Channel ID for each eTLD+1.

A detailed technical plan for its removal is described at https://docs.google.com/document/d/1phCknRCnrad7M4cgGusLpKz5A1lLzq0oShahlMgY29Q/edit.

That plan seems to put the feature behind a flag rather than remove its code, and states that it will initially disable it only in TLS-1.3 0-RTT scenarios. Is that still the plan? Or are you planning to remove/disable it in all scenarios?

I am planning to disable and then remove in all scenarios. The impetus for this work is TLS 1.3 0-RTT. My plan is to introduce the base::Feature (defaulting to Channel ID disabled) and remove it entirely in the following release, unless that seems to be overkill.

 

 

Motivation
Channel ID was never standardized, and has only been implemented by Google. Attempts at standardization lead to Token Binding, covered in a separate Intent to Ship (https://groups.google.com/a/chromium.org/d/msg/blink-dev/C-iuVJeDGkk/IfIam8_rFgAJ).

Is there progress on that intent? Not that it's a blocker, but would be good to see progress on that front.

There's progress being made on it. Right now it's waiting on https://github.com/whatwg/fetch/pull/325. 

 

The design of Channel ID imposes multiple burdens and limitations on the network stack. Channel ID’s proof of possession is done once at the beginning of the TLS handshake, instead of provided on each HTTP request. This connection-based authentication (instead of request-based authentication) leads to added complexity in the implementation. The introduction of Channel ID resulted in splitting socket pools in two, having “privacy mode” (without Channel ID) and non privacy mode (with Channel ID) socket pools because of the ambient authentication carried from per-connection instead of per-request authentication. Channel ID also requires us to tear down connections when users delete browsing data. Channel ID prevents HTTP/2 connection coalescing across multiple domains (e.g. google.com and youtube.com). Channel ID is incompatible with the 0-RTT mode of TLS 1.3.

That's a long list of serious limitations, so would be happy to see that resolved.

Does Token Binding get rid of all these limitations?

Token Binding does not have the connection-based/ambient authentication problem of Channel ID. It also does not have the HTTP/2 connection coalescing problem. There's been some work in the 0-RTT space for Token Binding (see https://datatracker.ietf.org/doc/draft-ietf-tokbind-tls13-0rtt/).

 

Interoperability and Compatibility Risk
Chrome is the only UA that implements Channel ID. Google’s servers are the only known servers to implement the feature, and they have no known behavior that requires Channel ID (such behavior would require Chrome to be the UA). There is little interoperability risk to removing Channel ID.

There is some compatibility risk to the removal of Channel ID. Since a server may choose to bind cookies to the Channel ID, when Channel ID is removed the server may have a one-time rejection of cookies. Once the server rejects and reissues cookies (or updates server-side session state to indicate there is no more Channel ID binding), the removal of Channel ID causes no more problems; the server behaves the same as any other browser that never supported Channel ID.

Edge: not supported
Firefox: not supported
Safari: not supported

Alternative implementation suggestion for web developers
A combination of WebCrypto and Service Workers may be able to provide similar functionality, depending on the server’s use case. Token Binding is intended as a direct replacement for Channel ID, which may be available in the future. TLS client certificates could also be used.

Usage information from UseCounter
No usage information from UseCounter. The only known servers to use Channel ID are Google servers. Removal will result in falling back to behavior used for other browsers; users should not notice this change.

Requesting approval to remove too?
Yes

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

[Yoav Weiss]

On Tue, Apr 3, 2018 at 7:58 PM Nick Harper <nha...@chromium.org> wrote:

On Tue, Apr 3, 2018 at 1:39 AM, Yoav Weiss <yo...@yoav.ws> wrote:

On Fri, Mar 30, 2018 at 11:26 PM Nick Harper <nha...@chromium.org> wrote:

Re-sending to blink-dev

On Fri, Mar 30, 2018 at 2:14 PM, Nick Harper <nha...@chromium.org> wrote:

Primary eng (and PM) emails
nha...@chromium.org

Summary
Channel ID is a network feature where on each TLS connection to a server that supports Channel ID, the client proves possession of a private key, allowing the server to bind credentials to the Channel ID key, accepting them only when the Channel ID is also provided. Once a Channel ID is created for a site, Chrome does not change that Channel ID (unless the user clears cookies/browsing data for that site); Chrome uses a separate Channel ID for each eTLD+1.

A detailed technical plan for its removal is described at https://docs.google.com/document/d/1phCknRCnrad7M4cgGusLpKz5A1lLzq0oShahlMgY29Q/edit.

That plan seems to put the feature behind a flag rather than remove its code, and states that it will initially disable it only in TLS-1.3 0-RTT scenarios. Is that still the plan? Or are you planning to remove/disable it in all scenarios?

I am planning to disable and then remove in all scenarios. The impetus for this work is TLS 1.3 0-RTT. My plan is to introduce the base::Feature (defaulting to Channel ID disabled) and remove it entirely in the following release, unless that seems to be overkill.

Makes sense.

 

 

 

Motivation
Channel ID was never standardized, and has only been implemented by Google. Attempts at standardization lead to Token Binding, covered in a separate Intent to Ship (https://groups.google.com/a/chromium.org/d/msg/blink-dev/C-iuVJeDGkk/IfIam8_rFgAJ).

Is there progress on that intent? Not that it's a blocker, but would be good to see progress on that front.

There's progress being made on it. Right now it's waiting on https://github.com/whatwg/fetch/pull/325. 

 

The design of Channel ID imposes multiple burdens and limitations on the network stack. Channel ID’s proof of possession is done once at the beginning of the TLS handshake, instead of provided on each HTTP request. This connection-based authentication (instead of request-based authentication) leads to added complexity in the implementation. The introduction of Channel ID resulted in splitting socket pools in two, having “privacy mode” (without Channel ID) and non privacy mode (with Channel ID) socket pools because of the ambient authentication carried from per-connection instead of per-request authentication. Channel ID also requires us to tear down connections when users delete browsing data. Channel ID prevents HTTP/2 connection coalescing across multiple domains (e.g. google.com and youtube.com). Channel ID is incompatible with the 0-RTT mode of TLS 1.3.

That's a long list of serious limitations, so would be happy to see that resolved.

Does Token Binding get rid of all these limitations?

Token Binding does not have the connection-based/ambient authentication problem of Channel ID. It also does not have the HTTP/2 connection coalescing problem. There's been some work in the 0-RTT space for Token Binding (see https://datatracker.ietf.org/doc/draft-ietf-tokbind-tls13-0rtt/).

That's great to hear. LGTM1

 

 

Interoperability and Compatibility Risk
Chrome is the only UA that implements Channel ID. Google’s servers are the only known servers to implement the feature, and they have no known behavior that requires Channel ID (such behavior would require Chrome to be the UA). There is little interoperability risk to removing Channel ID.

There is some compatibility risk to the removal of Channel ID. Since a server may choose to bind cookies to the Channel ID, when Channel ID is removed the server may have a one-time rejection of cookies. Once the server rejects and reissues cookies (or updates server-side session state to indicate there is no more Channel ID binding), the removal of Channel ID causes no more problems; the server behaves the same as any other browser that never supported Channel ID.

Edge: not supported
Firefox: not supported
Safari: not supported

Alternative implementation suggestion for web developers
A combination of WebCrypto and Service Workers may be able to provide similar functionality, depending on the server’s use case. Token Binding is intended as a direct replacement for Channel ID, which may be available in the future. TLS client certificates could also be used.

Usage information from UseCounter
No usage information from UseCounter. The only known servers to use Channel ID are Google servers. Removal will result in falling back to behavior used for other browsers; users should not notice this change.

Requesting approval to remove too?
Yes

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

[Mike West]

Connection-based authentication is something I'll be happy for us to get rid of. The request-based model Token Binding offers is a better approach to addressing the use case Channel ID targets, and based on the Fetch review, is getting uptake from other vendors.

Deprecating/removing Channel ID LGTM2.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACj%3DBEiDGXwptW3Dwp2sZH4KnZZUFMEpWLHa68AyPbt-YP%2Bfdw%40mail.gmail.com.

[Jochen Eisinger]

removing channel id lgtm3

As Token Binding is not yet in a state we can ship it, I'd caution against relying on that it will come, but I agree with Mike that getting rid of connection based authentication is good.

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/CAKXHy%3DdDYQCdVWvaO23iEbpN--%2B%2BX7cSC17yaH4kenGyCSSJdA%40mail.gmail.com.