Intent to Ship: New ALPS code point

[Victor Tan]

Contact emails

vict...@chromium.org, mike...@chromium.org, davi...@chromium.org

Explainer

https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md 

Specification

https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability  

https://tools.ietf.org/html/draft-vvv-httpbis-alps 

https://tools.ietf.org/html/draft-vvv-tls-alps    

 

Summary

Shipping a new code point (17613) for TLS ALPS extension to allow adding more data in the ACCEPT_CH HTTP/2 and HTTP/3 frame. The ACCEPT_CH HTTP/2 frame with the existing TLS ALPS extension code point (17513) had an arithmetic overflow bug in the Chrome ALPS decoder. It limits the capability to add more than 128 bytes data (in theory, the problem range is 128 bytes to 255 bytes) to the ACCEPT_CH frame. With the new ALPS code point, we can fully mitigate the issue.

Blink component

Blink>Network>ClientHints

TAG review

https://github.com/w3ctag/design-reviews/issues/549 

TAG review status

Closed

Risks
Interoperability and Compatibility

This is switching to a new code point for the TLS ALPS extension. It won’t change the design of ALPS and ACCEPT_CH mechanism implementation.  The main source of compatibility risk is that it causes conflicts with ALPS negotiation since some clients could still use the old code point while others are switching to use the new code point.  The ALPS extension could be ignored if the code point doesn’t match during negotiation, which means the server's client hints preferences won’t be delivered in the ACCEPT_CH HTTP/2 and HTTP/3 frame.  We mitigate this by enabling servers to support both code points, monitoring both code points usage and removing the old ALPS code point support in a future intent once the usage is low enough. We also split the rollout into two phases: we first start to enable the new ALPS code point for ACCEPT_CH  with HTTP/3 frame in a slow rollout, and then eventually enable the new code point with HTTP/2 frame.

Edge: No signals

Firefox: Pending https://github.com/mozilla/standards-positions/issues/510
Safari: Pending https://lists.webkit.org/pipermail/webkit-dev/2021-April/031768.html

Web/Framework developers: https://twitter.com/Sawtaytoes/status/1369031447940526080 https://twitter.com/_jayphelps/status/1369023028735148032

Activation

The site’s TLS and HTTP serving application would need to be updated to support this new code point. We aren’t aware of many sites using this feature yet, however.

Debuggability

No special DevTools support needed. The effects of the code point change of ACCEPT_CH frame will be visible in the DevTools’ network tab. Also, the NetLog will record the ACCEPT_CH frame value if TLS ALPS extension is negotiated successfully. 

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

Yes

Is this feature fully tested by web-platform-tests?

No, this feature is tested with browser-side tests. We can’t test TLS-adjacent features currently through web-platform-tests. See this issue: https://github.com/web-platform-tests/wpt/issues/20159   

Flag name

UseNewAlpsCodepointHttp2

UseNewAlpsCodepointQUIC

Tracking bug

b/289087287 

Launch bug

https://launch.corp.google.com/launch/4299022 

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5149147365900288

[Yoav Weiss (@Shopify)]

On Saturday, January 13, 2024 at 12:08:33 AM UTC+1 Victor Tan wrote:

Contact emails

vict...@chromium.org, mike...@chromium.org, davi...@chromium.org

Explainer

https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md 

Specification

https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability  

https://tools.ietf.org/html/draft-vvv-httpbis-alps 

https://tools.ietf.org/html/draft-vvv-tls-alps    

 

Summary

Shipping a new code point (17613) for TLS ALPS extension to allow adding more data in the ACCEPT_CH HTTP/2 and HTTP/3 frame. The ACCEPT_CH HTTP/2 frame with the existing TLS ALPS extension code point (17513) had an arithmetic overflow bug in the Chrome ALPS decoder. It limits the capability to add more than 128 bytes data (in theory, the problem range is 128 bytes to 255 bytes) to the ACCEPT_CH frame. With the new ALPS code point, we can fully mitigate the issue.

Blink component

Blink>Network>ClientHints

TAG review

https://github.com/w3ctag/design-reviews/issues/549 

TAG review status

Closed

Risks
Interoperability and Compatibility

This is switching to a new code point for the TLS ALPS extension. It won’t change the design of ALPS and ACCEPT_CH mechanism implementation.  The main source of compatibility risk is that it causes conflicts with ALPS negotiation since some clients could still use the old code point while others are switching to use the new code point.  The ALPS extension could be ignored if the code point doesn’t match during negotiation, which means the server's client hints preferences won’t be delivered in the ACCEPT_CH HTTP/2 and HTTP/3 frame.  We mitigate this by enabling servers to support both code points, monitoring both code points usage and removing the old ALPS code point support in a future intent once the usage is low enough. We also split the rollout into two phases: we first start to enable the new ALPS code point for ACCEPT_CH  with HTTP/3 frame in a slow rollout, and then eventually enable the new code point with HTTP/2 frame.

Does the server have an indication if the client in question supports the newer code point?

If not, what would we expect servers that support the newer code point to do?

[Victor Tan]

If the server received the new code point, while it doesn't support, the ALPS extension will ignore. This also mean client might not know the server's client hints preferences before the first request. Currently, only few sites using the ALPS extension.  As TLS extension is negotiated, the server need to support both code points during the transition period, after some time, the server can drop the old one. 

[Manuel Rego Casasnovas]

On 13/01/2024 00:08, Victor Tan wrote:
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/549
> <https://github.com/w3ctag/design-reviews/issues/549>

TAG review is from 2021, has anything changed since then or is it still
the same feature/spec that is shipping now?

> Firefox: Pending https://github.com/mozilla/standards-positions/issues/510
> <https://github.com/mozilla/standards-positions/issues/510>

That's also quite old. Could you do a ping there, explaining the
willingness to ship in Blink, trying to reactivate it?

> Safari: Pending
> https://lists.webkit.org/pipermail/webkit-dev/2021-April/031768.html
> <https://lists.webkit.org/pipermail/webkit-dev/2021-April/031768.html>

For WebKit I think we should fill a new standards position request at:
https://github.com/WebKit/standards-positions/issues

Thanks,
Rego

[Chris Harrelson]

Please also fill out the various review gates (Privacy, Security, etc) in the chromestatus entry.

--
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/7ee096c8-22c1-4fcc-a2b4-c52de0010e5d%40igalia.com.

[Victor Tan]

> TAG review is from 2021, has anything changed since then or is it still the same feature/spec that is shipping now?

It's the same feature already shipping in the Blink. I don't think we have change anything for the ALPS. This intend is only a TLS extension code point change. 

what we do is trying to mitigate a bug in the old code point, not to re-active or de-active any feature. 

[Mike Taylor]

In our OWNERS meeting this week, there was some confusion on what's being proposed here (which is understandable, this isn't quite a typical intent for web exposed feature). Here's a summary of what we're trying to accomplish:

1) We shipped support for the ACCEPT_CH frame over h2 and h3 back in M96, which relies on the TLS ALPS protocol extension.
2) There are 2 parts to this: the client being able to understand ALPS/ACCEPT_CH (and in return do something useful), and the server being able to send it.
3) Because of a (long fixed) bug present in Chromium's implementation, it's risky for a server to send too much data via ACCEPT_CH, so it's usefulness is potentially limited.
4) In order to guarantee that older clients don't have this bug, we propose to rev the version (aka, code point) at the protocol layer. This way, if a server sends the new code point and the client understands it, it can send a larger payload without triggering the bug (which may result in sad things like a connection being refused).
5) This is sort of web observable, but right now if servers that support the old code point continue to send the old code point - nothing will break. Chromium will support both for now, with hopes to deprecate and remove the older one in the future when we're confident it won't result in performance regressions for servers sending ACCEPT_CH (since this is a performance optimization).

I hope that helps clear it up, and I'm sure Victor or David will chime in if I'm getting something wrong. :)

And to be clear - this isn't a request for a deprecation or removal (yet), but for shipping the new code point.

[Chris Harrelson]

Thanks for clarifying. Last question: where in the specifications is the new 17613 code point documented?

--

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/c704d985-a5cc-4e5e-99b0-1f78cc4428e6%40chromium.org.

[Victor Tan]

Currently, It's on the code: https://boringssl.googlesource.com/boringssl/+/master/include/openssl/tls1.h?pli=1#247

Once we standardize the ALPS RFC draft, we can finalize the value.  Hope this helps. 

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

[Yoav Weiss (@Shopify)]

Is the old code point defined somewhere? Would it be possible to add such a definition to one of the I-Ds? Or is this something that's not traditionally defined in IETF drafts?

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

[Erik Anderson]

Is the ALPS draft being actively worked on?

 

Various teams at Microsoft that own web sites leveraging client hints have expressed interest in using it, but the lack of a finalized standard has significantly slowed conversations with the teams that own the server code that would need to add support first.

 

Are you looking for help in moving standardization forward?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJQu%2BjtN9hQ302XVW1_Y1b8BUYQUDr4ujMavPU1vU7%2Bzw%40mail.gmail.com.

[Victor Tan]

Hi Erik,

We are actively working on it, but we need to put more efforts to standardization. 

In the last serval IETF, David is the only person is talking about the ALPS feature.  We'd glad to combine more efforts to move it forward to standardization.

Bests,

Victor 

[Victor Tan]

To be clarify,  currently David is not working on the standardizing ALPS feature.  

[Rick Byers]

Oof, I agree it's not good that the only documentation for the actual code point value is in Chromium code - that's the sort of thing our blink I2S process is supposed to prevent. In addition to confusion, there's also potential IP-risk downsides to this. Our blink process is generally to block shipping on the existence of some specification for everything necessary for a compatible implementation in a forum that ensures IP protection. While this isn't typically an adoption barrier for many companies, I know it has been in the past for some (including Microsoft). This doesn't mean we have to block on getting consensus in the "right" standards venue, we can just do a monkey-patch spec in a venue like the WICG, or an unlanded PR in a formal WG where the PR counts as an IP contribution. Then we can ship it as an "incubation" while doing the standards maturation work in parallel. Erik, can you comment on the extent to which such incubation spec work would help with Microsoft adoption?

Victor, is there any chance you can throw something together quickly (spec PR or monkey-patch) that would cover the gaps in what's necessary for compatible implementations? This particular delta seems very tiny and straightforward to me, so I was originally thinking I'd just approve it. But in principle I don't think we should be continuing to approve changes to APIs which we realize are struggling with adoption due to the standards work not quite being up to our I2S bar.

Erik, thank you for your offer of help on the standardization front! It definitely sounds to me like we should be pushing on the full standards effort in parallel to this specific intent. Having Microsoft and Google work together on that would hopefully be able to accelerate it.

Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fbfcefbb-637e-428b-9ca2-3c879e2af1e2n%40chromium.org.

[Yoav Weiss (@Shopify)]

On Wed, Jan 24, 2024 at 4:48 PM Rick Byers <rby...@chromium.org> wrote:

Oof, I agree it's not good that the only documentation for the actual code point value is in Chromium code - that's the sort of thing our blink I2S process is supposed to prevent. In addition to confusion, there's also potential IP-risk downsides to this. Our blink process is generally to block shipping on the existence of some specification for everything necessary for a compatible implementation in a forum that ensures IP protection. While this isn't typically an adoption barrier for many companies, I know it has been in the past for some (including Microsoft). This doesn't mean we have to block on getting consensus in the "right" standards venue, we can just do a monkey-patch spec in a venue like the WICG, or an unlanded PR in a formal WG where the PR counts as an IP contribution. Then we can ship it as an "incubation" while doing the standards maturation work in parallel. Erik, can you comment on the extent to which such incubation spec work would help with Microsoft adoption?

Victor, is there any chance you can throw something together quickly (spec PR or monkey-patch) that would cover the gaps in what's necessary for compatible implementations? This particular delta seems very tiny and straightforward to me, so I was originally thinking I'd just approve it. But in principle I don't think we should be continuing to approve changes to APIs which we realize are struggling with adoption due to the standards work not quite being up to our I2S bar.

+1 to defining these codepoints somewhere. Where are such codepoints typically defined? I'd have assumed they'd go into one of the relevant I-Ds..

[Victor Tan]

Rick, thanks for question, I will create a PR on the ALPS RFC draft to document the new code point regarding the early experiment. 

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

[Erik Anderson]

Thanks, it will be helpful to make sure this is documented outside of Chromium. I will also chat with some folks on Microsoft’s end that both own server implementations and have more IETF experience to explore how we can help with moving things forward.

 

From: Victor Tan <vict...@chromium.org>
Sent: Wednesday, January 24, 2024 9:00 AM
To: blink-dev <blin...@chromium.org>
Cc: Yoav Weiss <yoav...@chromium.org>; blink-dev <blin...@chromium.org>; Erik Anderson <Erik.A...@microsoft.com>; Chris Harrelson <chri...@chromium.org>; David Benjamin <davi...@chromium.org>; Mike Taylor <mike...@chromium.org>; Victor Tan <vict...@chromium.org>; Rick Byers <rby...@chromium.org>
Subject: Re: [blink-dev] Re: Intent to Ship: New ALPS code point

 

You don't often get email from vict...@chromium.org. Learn why this is important

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fbfcefbb-637e-428b-9ca2-3c879e2af1e2n%40chromium.org.

[Victor Tan]

create a PR for the code point change on the RFC draft, will work on there: https://github.com/vasilvv/tls-alps/pull/15, thanks. 

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

[Victor Tan]

the code point PR is merged. Feel free to take a look again. Thanks. 

[Yoav Weiss (@Shopify)]

LGTM1

Thanks for including these values in the I-D.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fbfcefbb-637e-428b-9ca2-3c879e2af1e2n%40chromium.org.

[Domenic Denicola]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2B5KAs3j9izP4t1p%2B9cPAkQ_PJ1ffuWHxMnL08P60EmVw%40mail.gmail.com.

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8zuWnfXL_NP11_sE2GC97%2BA%2BPet4ywvzT1fzqPZsXjeA%40mail.gmail.com.