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.

Reply via email to