LGTM1 On Wed, Sep 27, 2023 at 11:50 AM Philipp Hancke < philipp.han...@googlemail.com> wrote:
> Am Mi., 27. Sept. 2023 um 08:07 Uhr schrieb Yoav Weiss < > yoavwe...@chromium.org>: > >> >> >> 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! >>> >> > heh, great original I2S ;-) > > >> 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? >> > > It is guarded with WebRTC's internal FieldTrial which is overridden with a > base::FieldTrial in magic build ways. > > Also, I assume the TLS side of things went smoothly. Any reason to believe >> DTLS would be significantly worse? >> > > It did (see here > <https://bugs.chromium.org/p/webrtc/issues/detail?id=15467#c2>). Our very > own dreaded middleboxes (SBC or "Session Border Controller"; callcenters > use them) tend to be conservative in terms of deployment (see e.g. this > comment <https://bugs.chromium.org/p/webrtc/issues/detail?id=10261#c23>) > but most of them use a single vendor for browser interop testing who can > help with reaching out (in addition to discuss-webrtc and the release > notes) which should minimize the potential for breakage. > > >> >>>> >>>> *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/CAL5BFfXC8ZBmahmnf%2BBrVdz_cvzrckVkrH9_Of1m-Q5u8d1M4w%40mail.gmail.com.
