Intent to Ship: DTLS ClientHello extension permutation (WebRTC)

215 views
Skip to first unread message

Philipp Hancke

unread,
Sep 22, 2023, 2:00:42 AM9/22/23
to blink-dev, Harald Alvestrand, Philipp Hancke

Contact emails

Specification

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

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?

No

Flag name on chrome://flags

None

Finch feature name

WebRTC-PermuteTlsClientHello

Requires code in //chrome?

False

Tracking bug

Estimated milestones

Shipping on desktop120


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

This intent message was generated by Chrome Platform Status.

David Adrian

unread,
Sep 26, 2023, 3:47:50 PM9/26/23
to Philipp Hancke, blink-dev, Harald Alvestrand, Philipp Hancke

--
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+...@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.

Yoav Weiss

unread,
Sep 27, 2023, 2:07:07 AM9/27/23
to David Adrian, Philipp Hancke, blink-dev, Harald Alvestrand, Philipp Hancke
On Tue, Sep 26, 2023 at 9:47 PM 'David Adrian' via blink-dev <blin...@chromium.org> wrote:

On Fri, Sep 22, 2023 at 12:00 AM 'Philipp Hancke' via blink-dev <blin...@chromium.org> wrote:

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

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?
 

Philipp Hancke

unread,
Sep 27, 2023, 5:50:57 AM9/27/23
to Yoav Weiss, David Adrian, blink-dev, Harald Alvestrand, Philipp Hancke
Am Mi., 27. Sept. 2023 um 08:07 Uhr schrieb Yoav Weiss <yoav...@chromium.org>:


On Tue, Sep 26, 2023 at 9:47 PM 'David Adrian' via blink-dev <blin...@chromium.org> wrote:

heh, great original I2S ;-)
 
On Fri, Sep 22, 2023 at 12:00 AM 'Philipp Hancke' via blink-dev <blin...@chromium.org> wrote:

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

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). 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)
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.

Yoav Weiss

unread,
Sep 27, 2023, 6:03:11 AM9/27/23
to Philipp Hancke, David Adrian, blink-dev, Harald Alvestrand, Philipp Hancke
LGTM1 

Daniel Bratell

unread,
Sep 27, 2023, 10:56:54 AM9/27/23
to Yoav Weiss, Philipp Hancke, David Adrian, blink-dev, Harald Alvestrand, Philipp Hancke

LGTM2

/Daniel

Chris Harrelson

unread,
Sep 27, 2023, 11:58:13 AM9/27/23
to Daniel Bratell, Yoav Weiss, Philipp Hancke, David Adrian, blink-dev, Harald Alvestrand, Philipp Hancke
LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/75b98b41-d737-403c-82ae-9ebc6646cee7%40gmail.com.
Reply all
Reply to author
Forward
0 new messages