Contact emails phan...@microsoft.com, h...@chromium.org Specification https://datatracker.ietf.org/doc/rfc8446
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. *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.
