LGTM3 On Wed, Sep 27, 2023 at 8:11 AM Daniel Bratell <bratel...@gmail.com> wrote:
> LGTM2 (for the original request, just to be clear) > > I assume it will have the normal flag that will allow it to be turned off > if our interpretation is incorrect, since it is so hard to measure with a > high accuracy. > > /Daniel > On 2023-09-26 18:33, David Benjamin wrote: > > To clarify, I meant that we should apply this to WebRTC *in a > separate launch*. This one will just be HTTPS. We don't have numbers or a > flag for WebRTC right now, and we usually end up doing WebRTC separately > anyway, for better or worse. :-) > > On Tue, Sep 26, 2023 at 12:31 PM David Benjamin <david...@chromium.org> > wrote: > >> Ah yeah, we should apply this to WebRTC too. Based on the kinds of issues >> we've seen, hopefully that one will be easy (I wouldn't expect WebRTC to be >> impacted by the kinds of server bugs we've seen), but certainly we'll need >> numbers. >> >> Measurement is a little complicated for HTTPS (we had to do this fallback >> dance to avoid a ton of false positives on old Schannel behavior, which is >> why we had to pick up transient network errors as a different source of >> false positives). But since WebRTC talks to different kinds of peers, I >> suspect you all can just histogram the server-selected algorithm with >> SSL_get_peer_signature_algorithm, and just assume that's an accurate enough >> predictor. (TLS is client-offer / server-select, so we never learn the >> server's full capabilities, only what it happened to pick in response to >> our ClientHello. This makes measurements inherently more complex >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/RShdgyaDoX4/m/ly5-WQEBBgAJ> >> than measuring JavaScript API usage, but in simple cases just measuring >> the server selection gives good enough numbers.) >> >> On Tue, Sep 26, 2023 at 5:26 AM Philipp Hancke < >> philipp.han...@googlemail.com> wrote: >> >>> Should/can this also be applied to WebRTC's DTLS connections? >>> >>> (we don't have numbers but that can be fixed) >>> >>> Am Mo., 25. Sept. 2023 um 19:13 Uhr schrieb Yoav Weiss < >>> yoavwe...@chromium.org>: >>> >>>> LGTM1 to remove support, given that 0.009% of TLS connections divided >>>> by ~30 is roughly at our typical threshold. Also given the dominance of >>>> subresource TLS connections, it's likely that breakage would hit one of >>>> those subresources, making it less likely to cause functional damage >>>> (compared to e.g. the navigation request TLS connection). >>>> >>>> On Mon, Sep 25, 2023 at 6:03 PM David Adrian <dadr...@google.com> >>>> wrote: >>>> >>>>> There are approximately 30x TLS connections relative to pageloads, due >>>>> to subresources. Once you have a TLS connection open for a main frame, I'm >>>>> not sure how many page loads happen across it. Probably a lot, but it's >>>>> still dominated by subresources. >>>>> >>>>> In practice, the 0.02% bound appears to have shaken out to sub 0.01% >>>>> (0.009%), determined by looking at differences in the "OK" result for >>>>> Net.SSL_Connection_Error. >>>>> >>>>> On Tue, Sep 19, 2023 at 8:59 PM Yoav Weiss <yoavwe...@chromium.org> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Sep 20, 2023 at 12:47 AM David Benjamin < >>>>>> david...@chromium.org> wrote: >>>>>> >>>>>>> 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 emails dadr...@google.com >>>>>>>>>>>>> >>>>>>>>>>>>> Explainer None >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 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. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Specification https://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 component Internals>Network>SSL >>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ESSL> >>>>>>>>>>>>> >>>>>>>>>>>>> Search tags tls <https://chromestatus.com/features#tags:tls>, >>>>>>>>>>>>> ssl <https://chromestatus.com/features#tags:ssl>, sha1 >>>>>>>>>>>>> <https://chromestatus.com/features#tags:sha1> >>>>>>>>>>>>> >>>>>>>>>>>>> TAG review None >>>>>>>>>>>>> >>>>>>>>>>>>> TAG review status Not 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. >>>>>>> >>>>>> >>>>>> For web platform features, where we have both usecounters in the >>>>>> HTTPArchive and potentially UKM, we can gather potentially breaking >>>>>> URLs/origins, grab a few dozens random names from the list and deep dive >>>>>> into them to see if they show breakage or not. >>>>>> >>>>>> I'm not sure that we have anything similar for the netstack, where we >>>>>> could e.g. report the failures in ways that enable us to later follow up >>>>>> and run a similar manual check. (e.g. by reporting the failing DNS name >>>>>> and/or IP) >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> 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). >>>>>>> >>>>>> >>>>>> OK, that seems better, as presumably the denominator is smaller then >>>>>> it would be for page loads (which is what we typically use). Do you have >>>>>> a >>>>>> sense of the difference between denominators? (so, how many page loads >>>>>> typically happen per TLS connection?) >>>>>> >>>>>> >>>>>>> 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://flags use-sha1-server-handshakes >>>>>>>>>>>>> >>>>>>>>>>>>> Finch feature name DisableSHA1ServerSignature >>>>>>>>>>>>> >>>>>>>>>>>>> Requires code in //chrome? False >>>>>>>>>>>>> >>>>>>>>>>>>> Tracking bug >>>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=658905 >>>>>>>>>>>>> >>>>>>>>>>>>> Launch bug https://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 discussions Intent 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/CAL5BFfXorTe7SSPt8iZt5ZjVi0Qh8qd%2BPdEGMOzSQj45e0Z1VQ%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXorTe7SSPt8iZt5ZjVi0Qh8qd%2BPdEGMOzSQj45e0Z1VQ%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/CAF8qwaB5P6Ys%3DxMyB%3D7HvLJEa0Axp5uCcfbPQqurN2ADdasYgQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaB5P6Ys%3DxMyB%3D7HvLJEa0Axp5uCcfbPQqurN2ADdasYgQ%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/29ca51ba-5890-4767-82d1-0e4e21669374%40gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/29ca51ba-5890-4767-82d1-0e4e21669374%40gmail.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/CAOMQ%2Bw_Y9eDaxps5B6ToeF%3Dm3gZGOCCjY3Sj6FV5E%2BR2aij3WA%40mail.gmail.com.
