On Tue, Sep 19, 2023 at 1:50 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
> On Tue, Sep 19, 2023 at 7:45 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > >> On Tue, Sep 19, 2023 at 1:35 AM 'Jeffrey Yasskin' via blink-dev < >> blink-dev@chromium.org> wrote: >> >>> On Mon, Sep 18, 2023 at 4:11 PM David Adrian <dadr...@google.com> wrote: >>> >>>> > This should probably be an "Intent to Deprecate and Remove" rather >>>> than an "Intent to Ship". >>>> >>>> You're absolutely right that it should be, unfortunately that's not the >>>> subject Chrome Status generated. I'll file an issue. >>>> >>> >>> Oops, yes, you did everything right here. There's already >>> https://github.com/GoogleChrome/chromium-dashboard/issues/2749 about >>> changing this subject line, and now >>> https://github.com/GoogleChrome/chromium-dashboard/issues/3346 to align >>> the Chrome Status UI with the launching-features page. >>> >>> > The RFC's introduction at >>>> https://www.rfc-editor.org/rfc/rfc9155.html#name-introduction is a >>>> pretty good explainer for why we should remove SHA-1 signatures. >>>> >>>> Agreed. Noting in general, there is a large process mismatch between >>>> TLS launches and the Blink launch process, as discussed in >>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/CmlXjQeNWDI/m/r-AUe0OqAQAJ. >>>> That's why this Intent looks a little different. >>>> >>> >> I wouldn't categorize it as a large process mismatch. But that's an >> orthogonal discussion. >> >> >>> >>>> As for the launch itself, I'll note it's been at 10% on Finch for a >>>> couple weeks and everything looks gray, so we should be safe to ramp up to >>>> 100%. The only thing of note was a correlation with an unrelated crash >>>> in Blink >>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1479083#c2>, >>>> since the deprecation rollout was fairly large. It only showed at 10%, not >>>> 1%. >>>> >>> > How would we know of breakage in those 10%? Would that look like users > filing issues? Something else? > > >>>> On Mon, Sep 18, 2023 at 3:53 PM Jeffrey Yasskin <jyass...@google.com> >>>> wrote: >>>> >>>>> This should probably be an "Intent to Deprecate and Remove" >>>>> <https://www.chromium.org/blink/launching-features/#feature-deprecations> >>>>> rather than an "Intent to Ship". I'll let an API owner say if there's a >>>>> reason to re-send it; probably there isn't. >>>>> >>>>> On Mon, Sep 18, 2023 at 3:47 PM 'David Adrian' via blink-dev < >>>>> blink-dev@chromium.org> wrote: >>>>> >>>>>> Contact emailsdadr...@google.com >>>>>> >>>>>> ExplainerNone >>>>>> >>>>> >>>>> The RFC's introduction at >>>>> https://www.rfc-editor.org/rfc/rfc9155.html#name-introduction is a >>>>> pretty good explainer for why we should remove SHA-1 signatures. >>>>> >>>>> >>>>>> Specificationhttps://www.rfc-editor.org/rfc/rfc9155.html >>>>>> >>>>>> Summary >>>>>> >>>>>> Chrome is removing support for signature algorithms using SHA-1 for >>>>>> server signatures during the TLS handshake. This does not affect SHA-1 >>>>>> support in server certificates, which was already removed, or in client >>>>>> certificates, which continues to be supported. SHA-1 can be temporarily >>>>>> re-enabled via the temporary InsecureHashesInTLSHandshakesEnabled >>>>>> enterprise policy. This policy will be removed in Chrome 123. >>>>>> >>>>>> >>>>>> Blink componentInternals>Network>SSL >>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL> >>>>>> >>>>>> Search tagstls <https://chromestatus.com/features#tags:tls>, ssl >>>>>> <https://chromestatus.com/features#tags:ssl>, sha1 >>>>>> <https://chromestatus.com/features#tags:sha1> >>>>>> >>>>>> TAG reviewNone >>>>>> >>>>>> TAG review statusNot applicable >>>>>> >>>>>> Risks >>>>>> >>>>>> >>>>>> Interoperability and Compatibility >>>>>> >>>>>> At most 0.02% of page loads use the SHA1 fallback. However, we cannot >>>>>> disambiguate between a flaky first connection, and actually requiring >>>>>> SHA1. >>>>>> We expect the actual amount is lower. >>>>>> >>>>> >> Are we thinking that 0.02% is a loose upper bound? Is that correct? >> > As with anything in TLS, the protocol is client-offer / server-select, which means we pick up all the implications of that. We can measure what the server selects, but that doesn't actually tell us what will happen if we change the ClientHello: - Perhaps the server preferentially chooses SHA-1, but will pick SHA-2 if not offered. (I.e. SHA-1-preferring instead of SHA-1-requiring) - Perhaps the server picks SHA-2 regardless but, for some odd reason, breaks when SHA-1 is not offered. This could be a buggy, non-compliant fingerprinting script, or some weird behavior. Usually, these effects are small enough that we just measure the server selection and don't worry about it. Here, we could not do that. First, we knew from previously sampling sites that some servers (older IIS) fall in the first category. These servers would not break, but would seem to break if we measure the server selection. We also knew, again from sampling and due to the multiple places where this ClientHello field is used, the second category also shows up (in many cases, also older IIS). These servers would break but would seem not to if we measure the server selection. Thus, we used a different measurement strategy. We send a SHA-1-less ClientHello and then, on error, retry with SHA-1 restored. This does not work for security (an attacker can always force us onto the second round), but it helps counteract the above effects for a more accurate measurement... up to a point. Up to a point because, in exchange for clearing those effects, we pick a different effect: transient network errors will also trigger the retry. And thus our numbers inherently have noise at the scale of transient network errors. See also https://groups.google.com/a/chromium.org/g/blink-dev/c/RShdgyaDoX4/m/ly5-WQEBBgAJ, where we previously discussed this same client-offer / server-select property. This is a difference from web platform things, where we can simply observe in Chrome what APIs the site uses and moves on. > Any way to sample a few sites to validate that assumption? >> > I'm not sure what you mean. Networks occasionally flake, so any kind of fallback measurements will capture some flakiness. Sampling sites won't tell us anything about that. > Also, are those 0.02% driven by origins? Specific user platforms? > Something else? > This is 0.02% of TLS connections (sorry, page loads was a typo). This is another of those differences between networking and web platform features. The denominator is unavoidably different because of where in the stack this logic applies. Where it is actually an incompatibility with a site, it will be based on the origin. This is almost always due to a bug in the server software because every TLS 1.2 implementations supports SHA-2. (E.g. very very old OpenSSLs, with several known, unrelated security vulnerabilities have a bug where, with some server software, mess this up.) Where it is a transient network error above it is, well, a transient network error and presumably driven by network conditions. > >>>>>> *Gecko*: Positive ( >>>>>> https://github.com/mozilla/standards-positions/issues/812) >>>>>> >>>>>> *WebKit*: Positive ( >>>>>> https://github.com/WebKit/standards-positions/issues/196) >>>>>> >>>>>> *Web developers*: No signals >>>>>> >>>>>> *Other signals*: >>>>>> >>>>>> WebView application risks >>>>>> >>>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>>> that it has potentially high risk for Android WebView-based applications? >>>>>> >>>>>> None >>>>>> >>>>>> >>>>>> Debuggability >>>>>> >>>>>> n/a, this happens pre-devtools >>>>>> >>>>>> >>>>>> 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/+/main/docs/testing/web_platform_tests.md> >>>>>> ?No >>>>>> >>>>>> Flag name on chrome://flagsuse-sha1-server-handshakes >>>>>> >>>>>> Finch feature nameDisableSHA1ServerSignature >>>>>> >>>>>> Requires code in //chrome?False >>>>>> >>>>>> Tracking bug >>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=658905 >>>>>> >>>>>> Launch bughttps://launch.corp.google.com/launch/4233200 >>>>>> >>>>>> Estimated milestones >>>>>> Shipping on desktop 117 >>>>>> OriginTrial desktop last 116 >>>>>> OriginTrial desktop first 115 >>>>>> DevTrial on desktop 115 >>>>>> Shipping on Android 117 >>>>>> OriginTrial Android last 116 >>>>>> OriginTrial Android first 115 >>>>>> DevTrial on Android 115 >>>>>> OriginTrial webView last 116 >>>>>> OriginTrial webView first 115 >>>>>> >>>>>> Anticipated spec changes >>>>>> >>>>>> Open questions about a feature may be a source of future web compat >>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>> issues in the project for the feature specification) whose resolution may >>>>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>>>> of >>>>>> the API in a non-backward-compatible way). >>>>>> None >>>>>> >>>>>> Link to entry on the Chrome Platform Status >>>>>> https://chromestatus.com/feature/4832850040324096 >>>>>> >>>>>> Links to previous Intent discussionsIntent to Experiment: >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42JZz%3De_TRVwumqgTj-A7543BR7JLBUR_GzVN_oOWhKVvg%40mail.gmail.com >>>>>> >>>>>> >>>>>> This intent message was generated by Chrome Platform Status >>>>>> <https://chromestatus.com/>. >>>>>> >>>>>> -- >>>>>> 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/CAGkh42LiSGgfN1trVXfrmCW0Upk9r9GK4XYZQm5Y8RSzphn_DA%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42LiSGgfN1trVXfrmCW0Upk9r9GK4XYZQm5Y8RSzphn_DA%40mail.gmail.com?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/CANh-dXnM7SzAOh2y6hcuezDpo-yCW%3DtNg0%3D1ErEMCFN%3DSSpsQQ%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dXnM7SzAOh2y6hcuezDpo-yCW%3DtNg0%3D1ErEMCFN%3DSSpsQQ%40mail.gmail.com?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/CAL5BFfVPG6np80msDXGDyzqOMA6E-7mtqFQpDSw8w5m3X%3DEKOg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVPG6np80msDXGDyzqOMA6E-7mtqFQpDSw8w5m3X%3DEKOg%40mail.gmail.com?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/CAF8qwaB0d37_%2Ba5qrY%3Dt3UjGCs20kLmFdch_i%2BhSz0EY6%2Bbc7g%40mail.gmail.com.
