Closed Bug 1884140 Opened 4 months ago Closed 3 months ago

Enable DTLS1.3 in WebRTC for Firefox Release

Categories

(Core :: WebRTC, enhancement, P3)

Unspecified
All
enhancement

Tracking

()

RESOLVED FIXED
127 Branch
Tracking Status
firefox-esr115 --- wontfix
firefox127 --- fixed

People

(Reporter: anna.weine, Assigned: bwc)

References

(Depends on 1 open bug)

Details

Attachments

(3 files, 1 obsolete file)

Hi,

We (NSS) have recently improved the support of DTLS1.3. The DTLS1.3 code is now in Release.
What do you think about enabling DTLS1.3 in WebRTC for Release? Does it sound like it's worth doing? Any problems you expect?

Thanks

P.s. as far as I can see, we only need to change the pref: https://searchfox.org/mozilla-central/source/modules/libpref/init/all.js#342

Flags: needinfo?(docfaraday)
Severity: -- → S4
Priority: -- → P3

I think that would be reasonable to do. Martin, do you feel like it is time?

Flags: needinfo?(docfaraday) → needinfo?(mt)

I don't see any reason not to. This isn't without risk, but as long as Anna is comfortable helping with any tricky protocol-level diagnosis, offering this will put us in a strong position.

We likely won't see a lot of performance gain - there aren't that many direct Firefox-to-Firefox sessions. Most are terminated at servers.

Before doing this, I recommend re-activating the WEBRTC_DTLS_PROTOCOL_VERSION telemetry probe and maybe WEBRTC_DTLS_{CLIENT|SERVER}_FAILURE_TIME (a failure reason would be even better (see SSL_HANDSHAKE_RESULT). We let these probes expire, but having information about how adoption is going would seem to be wise.

Flags: needinfo?(mt)

Any reason not to convert those telemetry probes to Glean? I don't see us wanting to compare the long expired telemetry with the newer version.

Flags: needinfo?(mt)

By all means use Glean, if that is easier or better. Comparing with old behaviour isn't that useful, I agree.

Flags: needinfo?(mt)

I will be happy to help if anything goes wrong :)

Depends on: 1657808
OS: Unspecified → All

Hi, do you have any update on this?

Flags: needinfo?(docfaraday)
Assignee: nobody → docfaraday
Flags: needinfo?(docfaraday)

Should we go ahead and remove expired telemetry like WEBRTC_SRTP_CIPHER and WEBRTC_DTLS_CIPHER? Or start gathering that again with glean?

Flags: needinfo?(mt)

Removal seems sensible. As to whether you want to continue tracking it, that's up to you. I would. I've found that having this data is critical to understanding what to do with new ciphers (and it looks like there are some new ciphers coming).

Flags: needinfo?(mt)

Ok, new ciphers coming up definitely justifies some telemetry, I'll go ahead and add that in.

Depends on D208147

Attached file data-review-1884140.md
Attachment #9397907 - Flags: data-review?(chutten)

Comment on attachment 9397907 [details]
data-review-1884140.md

DATA COLLECTION REVIEW RESPONSE:

Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes.

Is there a control mechanism that allows the user to turn the data collection on and off?

Yes. This collection can be controlled through the product's preferences.

If the request is for permanent data collection, is there someone who will monitor the data over time?

No. This collection will expire in Firefox 135.

Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 1, Technical.

Is the data collection request for default-on or default-off?

Default on for all channels.

Does the instrumentation include the addition of any new identifiers?

No.

Is the data collection covered by the existing Firefox privacy notice?

Yes.

Does the data collection use a third-party collection tool?

No.


Result: datareview+

Attachment #9397907 - Flags: data-review?(chutten) → data-review+
Pushed by bcampen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d09724a12a23
Glean telemetry for webrtc DTLS. r=mjf
https://hg.mozilla.org/integration/autoland/rev/bd103d0b429a
Allow the use of DTLS 1.3 on release/beta. r=mjf
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 127 Branch

Is there a user impact that should translate into mentioning that change in our general, developer, or enterprise release notes? Thanks

Flags: needinfo?(docfaraday)

I think it is worth mentioning that webrtc will be using the latest version of the DTLS spec for encryption.

Flags: needinfo?(docfaraday)

Comment on attachment 9400444 [details]
Bug 1884140 - Adding WebRTC DTLS1.3 to FeatureManifest

Revision D209674 was moved to bug 1895498. Setting attachment 9400444 [details] to obsolete.

Attachment #9400444 - Attachment is obsolete: true
Attachment #9400444 - Attachment is obsolete: false

Comment on attachment 9400444 [details]
Bug 1884140 - Adding WebRTC DTLS1.3 to FeatureManifest

Revision D209674 was moved to bug 1895498. Setting attachment 9400444 [details] to obsolete.

Attachment #9400444 - Attachment is obsolete: true
Attachment #9400444 - Attachment description: WIP: Bug 1884140 - Adding WebRTC DTLS1.3 to FeatureManifest → Bug 1884140 - Adding WebRTC DTLS1.3 to FeatureManifest
Attachment #9400444 - Attachment is obsolete: false

Comment on attachment 9400444 [details]
Bug 1884140 - Adding WebRTC DTLS1.3 to FeatureManifest

Revision D209674 was moved to bug 1895498. Setting attachment 9400444 [details] to obsolete.

Attachment #9400444 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: