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?
On Mon, Jan 22, 2024 at 4:03 PM Victor Tan <victor...@chromium.org> wrote: > 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. > > On Saturday, January 20, 2024 at 7:50:46 PM UTC-5 Chris Harrelson wrote: > >> Thanks for clarifying. Last question: where in the specifications is the >> new 17613 code point documented? >> >> On Fri, Jan 19, 2024 at 12:59 PM Mike Taylor <miketa...@chromium.org> >> wrote: >> >>> 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. >>> On 1/17/24 11:16 AM, Victor Tan wrote: >>> >>> 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. >>> >>> On Wednesday, January 17, 2024 at 11:00:13 AM UTC-5 Yoav Weiss wrote: >>> >>>> On Saturday, January 13, 2024 at 12:08:33 AM UTC+1 Victor Tan wrote: >>>> >>>> Contact emails >>>> >>>> victor...@chromium.org, miketa...@chromium.org, david...@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 <https://crbug.com/1292069> 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 >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3ENetwork%3EClientHints%2C&can=2> >>>> >>>> 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? >>>> >>>> >>>> >>>> >>>> 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 >>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>> ? >>>> >>>> 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 >>>> >>>> -- >>> >> 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+unsubscr...@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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c704d985-a5cc-4e5e-99b0-1f78cc4428e6%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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+unsubscr...@chromium.org. 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.
