On Tue, Sep 26, 2023 at 9:47 PM 'David Adrian' via blink-dev < blink-dev@chromium.org> wrote:
> Great follow up to > https://groups.google.com/a/chromium.org/g/blink-dev/c/bYZK81WxYBo/m/lKLrZ_P2BwAJ. > Big fan! > > On Fri, Sep 22, 2023 at 12:00 AM 'Philipp Hancke' via blink-dev < > blink-dev@chromium.org> wrote: > >> Contact emails >> phan...@microsoft.com, h...@chromium.org >> >> Specification >> https://datatracker.ietf.org/doc/rfc8446 >> > This is an interesting simple case where I agree that an explainer for this would be superfluous (as the Summary sums up what you're planning to ship). > >> >> Summary >> >> Randomize the order of DTLS ClientHello extensions, to reduce potential >> ecosystem brittleness. >> >> >> This is a WebRTC specific follow-up to >> https://groups.google.com/a/chromium.org/g/blink-dev/c/bYZK81WxYBo/m/lKLrZ_P2BwAJ >> which >> launched successfully a while back. >> >> >> WebRTC uses DTLS (datagram TLS over UDP) multiplexed with STUN and RTP >> and also uses a SRTP specific extension (use_srtp defined in RFC 5764) to >> negotiate encryption keys. >> >> Middleboxes might expect the use_srtp flag in a certain position which >> changes with this feature. >> >> >> Blink component >> Blink>WebRTC >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebRTC> >> >> TAG review >> None >> >> TAG review status >> Not applicable >> >> Risks >> >> >> Interoperability and Compatibility >> >> It is possible that WebRTC's ClientHello extension ordering is already >> ossified. This change may cause compatibility issues with middleboxes, SBCs >> or other network monitoring software. We will do a slow rollout and monitor >> breakage. >> > Presumably, this will be behind a base feature to support the slow rollout? Also, I assume the TLS side of things went smoothly. Any reason to believe DTLS would be significantly worse? > >> >> *Gecko*: Positive ( >> https://github.com/mozilla/standards-positions/issues/709) Applied to >> TLS and DTLS equally >> >> *WebKit*: No signal ( >> https://github.com/WebKit/standards-positions/issues/92) >> >> *Web developers*: No signals >> >> *Other signals*: >> >> Ergonomics >> >> n/a, not developer facing >> >> >> Activation >> >> n/a, not developer facing >> >> >> Security >> >> Using a fixed extension order can encourage server implementers to >> fingerprint Chrome and then assume specific implementation behavior. This >> can limit ecosystem agility when Chrome implements future modifications to >> DTLS, if the server implementations are not prepared for Chrome to change >> its ClientHello. Chrome will randomly order extensions, subject to the >> pre_shared_key constraint in the RFC. This will reduce the risk of server >> and middleboxes fixating on details of our current ClientHello. This should >> make the DTLS ecosystem more robust to changes. >> >> >> 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, inner function of TLS stack. Possible to inspect using tools like >> Wireshark >> >> >> 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 >> None >> >> Finch feature name >> WebRTC-PermuteTlsClientHello >> >> Requires code in //chrome? >> False >> >> Tracking bug >> https://bugs.chromium.org/p/webrtc/issues/detail?id=15467 >> >> Estimated milestones >> Shipping on desktop 120 >> >> >> 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/5191245718880256 >> >> 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/CADxkKi%2BWEyR_PRHcAfNNR0w1SECOZ%2B3PqVN3x%3DGcYjK10tE6sg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKi%2BWEyR_PRHcAfNNR0w1SECOZ%2B3PqVN3x%3DGcYjK10tE6sg%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/CAGkh42Kvqkxyfk7QB9%2BAZcWoWhW9AnzoefP%2BDoxabushNh3VmA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42Kvqkxyfk7QB9%2BAZcWoWhW9AnzoefP%2BDoxabushNh3VmA%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/CAL5BFfU6O%2B0zqmE4HV38TOcZhpvwreki3-VTHWbsGQiofC_4Dg%40mail.gmail.com.