1615208 - Firefox Nightly/Chrome interop issue due to DTLS 1.3

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Philipp Hancke [:fippo]]

Attachment: handshake.pcapng

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

originally noticed by our (whereby) CI servers but since https://appr.tc/ is still the most vendor-neutral STR:

1. join apprtc room in chrome (stable or canary), have webrtc-internals open
2. join same room in Firefox Nightly (75.0a1)

Actual results:

It fails. In chrome's webrtc-internals the iceconnectionstate changes to connected but the connection state goes to failed which suggests a DTLS failure.

Firefox just enabled DTLS 1.3 and probably Chrome/webrtc.org does not handle the supported version in the handshake and responds with an error. See the attached pcap. I suspect the problem is in the "supported versions" which lists 0x7f1e, 0x303 (TLS 1.2) and 0x302 (TLS 1.1). It should have 0x304 for DTLS 1.3 according to https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/?include_text=1 no?

Expected results:

bidirectional video

Comment 1

[Philipp Hancke [:fippo]]

setting media.peerconnection.dtls.version.max to 771 (DTLS 1.2) fixes it. What is 0x7f1e even?!

Comment 2

[Nils Ohlmeier [:drno]]

This only happens with Chrome first, Firefox second. But works fine the other way around.

Comment 3

[Philipp Hancke [:fippo]]

Attachment: firefox-firefox handshake

dump from https://webrtc.github.io/samples/src/content/peerconnection/pc1/
-- still works but Wireshark doesn't like the DTLS handshake at all there.

Comment 4

[Kevin Jacobs [:kjacobs]]

0x7f1e is the draft version indicator (see here). I haven't found a Wireshark bug tracking their level of DTLS 1.3 support, but it's not entirely surprising that it may not comprehend DTLS1.3 - encrypted messages are indicated in a totally different way as of draft-27.

Under manual inspection, the garbled pcap looks well-formed, but it does appear that we may have an issue negotiating lower versions after offering 1.3. I'm continuing to look into this.

Comment 5

[Philipp Hancke [:fippo]]

that sounds like Chrome/boringssl isn't very forward compatible and does not ignore that. Maybe we should file a bug there (or in webrtc and let them shuffle it around)?

Comment 6

[Kevin Jacobs [:kjacobs]]

I see what's going on here. As you suggest, when Firefox constructs the supported_versions extension for the DTLS1.3 CH, the alternate versions (DTLS 1.2 and 1.0) do not have their encodings converted for DTLS. I.e., we advertise {0x7f1e, 0x0303, 0x0302} when we should instead advertise {0x7f1e, 0xfefd, 0xfeff}. BoringSSL doesn't find any known DTLS versions in the first list, and alerts. I've confirmed the handshake works as expected with this change.

Moving this bug into NSS.

Comment 7

[Kevin Jacobs [:kjacobs]]

Attachment: Bug 1615208 - Send DTLS version numbers in DTLS 1.3 supported_versions extension

This patch modifies supported_versions encodings to reflect DTLS versions when DTLS1.3 is use. Previously, a DTLS1.3 CH would include [0x7f1e, 0x303, 0x302] instead of the expected [0x7f1e, 0xfefd, 0xfeff], causing compatibility issues.

Comment 8

[Kevin Jacobs [:kjacobs]]

Thank you for the report!

https://hg.mozilla.org/projects/nss/rev/9e0d34a6cf91f52f7dbc5622a79777d6642fad54

Comment 9

[Philipp Hancke [:fippo]]

My CI tests for this just passed again with https://download-installer.cdn.mozilla.net/pub/firefox/nightly/latest-mozilla-central-l10n/firefox-75.0a1.en-US.linux-x86_64.tar.bz2
-- thank you!