2007200 - Support ExportKeyingMaterial for WebTransport

Status: RESOLVED FIXED

(Core :: Networking, enhancement, P2)

Description

[Randell Jesup [:jesup] (needinfo me)]

See https://www.w3.org/TR/webtransport/#webtransport-methods

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Bug 2007200: Implement exportKeyingMaterial() method r=saschanaz!

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Bug 2007200: Add wpt tests for WebTransport exportKeyingMaterial r=jib!

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Bug 2007200: Add WebTransport ExportKeyingMaterial backend r=#necko-reviewers!

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Bug 2007200: Hook up WebTransport exportKeyingMaterial to necko/neqo r=#necko-reviewers!

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Bug 2007200: Update exportKeyingMaterial WPTs for spec change r=jib!

Per w3c/webtransport#774, exportKeyingMaterial(label, context, outputLength)
takes all three arguments as required (context is no longer optional and the
prose no longer says "if context is given"). Implement outputLength end to end:
the DOM validates it (RangeError if 0 or > 4096) and plumbs it through IPC, the
necko nsIWebTransport interface, the Http3/Http2 sessions, and the neqo glue,
which now sizes the exporter output to outputLength instead of a hardcoded 32.

Rewrite the WPTs to the 3-argument form (asserting the output is outputLength
bytes, plus outputLength RangeError coverage) and drop the now-passing
idlharness exportKeyingMaterial expected-FAIL.

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

Attachment: WIP: Bug 2007200: make WebTransport exportKeyingMaterial args required and implement outputLength

Per w3c/webtransport#774, exportKeyingMaterial(label, context, outputLength)
takes all three arguments as required (context is no longer optional and the
prose no longer says "if context is given"). Implement outputLength end to end:
the DOM validates it (RangeError if 0 or > 4096) and plumbs it through IPC, the
necko nsIWebTransport interface, the Http3/Http2 sessions, and the neqo glue,
which now sizes the exporter output to outputLength instead of a hardcoded 32.

Rewrite the WPTs to the 3-argument form (asserting the output is outputLength
bytes, plus outputLength RangeError coverage) and drop the now-passing
idlharness exportKeyingMaterial expected-FAIL.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/f882f45e3103
https://hg.mozilla.org/integration/autoland/rev/ca41a57aa2b4
Implement exportKeyingMaterial() method r=saschanaz,webidl,tschuster,smaug
https://github.com/mozilla-firefox/firefox/commit/7bcd930d5d79
https://hg.mozilla.org/integration/autoland/rev/f9427dfe054a
Add WebTransport ExportKeyingMaterial backend r=necko-reviewers,kershaw
https://github.com/mozilla-firefox/firefox/commit/04e1ad930476
https://hg.mozilla.org/integration/autoland/rev/04122bc7f100
Hook up WebTransport exportKeyingMaterial to necko/neqo r=necko-reviewers,kershaw
https://github.com/mozilla-firefox/firefox/commit/a3d89ea678c8
https://hg.mozilla.org/integration/autoland/rev/dc7d8e0ce670
Add wpt tests for WebTransport exportKeyingMaterial r=jib
https://github.com/mozilla-firefox/firefox/commit/352ec53c7d9c
https://hg.mozilla.org/integration/autoland/rev/cb21b3eec5ef
2007206: apply code formatting via Lando

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/78a5278d9691
https://hg.mozilla.org/integration/autoland/rev/daa7a7b4892e
Revert "Bug 2007200, 2007206: apply code formatting via Lando" for causing wpt lint failures & build bustages @ TestHttp3ConnectUDPStream.cpp

Comment 9

[Sandor Molnar[:smolnar]]

Backed out for causing wpt lint failures & build bustages @ TestHttp3ConnectUDPStream.cpp

Backout link: https://hg.mozilla.org/integration/autoland/rev/daa7a7b4892e814fb53d8651a5e807db5d76d528

Push with failures

Failure log -> ERROR - /builds/worker/checkouts/gecko/netwerk/test/gtest/TestHttp3ConnectUDPStream.cpp(31,7): error: abstract class is marked 'final' [-Werror,-Wabstract-final-class]

Failures log ->TEST-UNEXPECTED-ERROR | /builds/worker/checkouts/gecko/testing/web-platform/tests/webtransport/export-keying-material.https.any.js:123 | Whitespace at EOL (TRAILING WHITESPACE)

Comment 10

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/61501 for changes under testing/web-platform/tests

Comment 11

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Bug 2007200: make WebTransport exportKeyingMaterial args required and implement outputLength r=#webidl!,#necko-reviewers!,#dom-core!

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/d0fc4b94fb7e
https://hg.mozilla.org/integration/autoland/rev/5e79b4fb08dd
Implement exportKeyingMaterial() method r=saschanaz,webidl,tschuster,smaug
https://github.com/mozilla-firefox/firefox/commit/65e72a996304
https://hg.mozilla.org/integration/autoland/rev/58159f5f6108
Add WebTransport ExportKeyingMaterial backend r=necko-reviewers,kershaw
https://github.com/mozilla-firefox/firefox/commit/451c5f579528
https://hg.mozilla.org/integration/autoland/rev/9f67d252dfde
Hook up WebTransport exportKeyingMaterial to necko/neqo r=necko-reviewers,kershaw
https://github.com/mozilla-firefox/firefox/commit/9d7262e33eb7
https://hg.mozilla.org/integration/autoland/rev/4b9f7380d121
Add wpt tests for WebTransport exportKeyingMaterial r=jib
https://github.com/mozilla-firefox/firefox/commit/cff1d8b5320a
https://hg.mozilla.org/integration/autoland/rev/4e2fc36feba8
apply code formatting via Lando

Comment 14

[amarc]

https://hg.mozilla.org/mozilla-central/rev/5e79b4fb08dd
https://hg.mozilla.org/mozilla-central/rev/58159f5f6108
https://hg.mozilla.org/mozilla-central/rev/9f67d252dfde
https://hg.mozilla.org/mozilla-central/rev/4b9f7380d121
https://hg.mozilla.org/mozilla-central/rev/4e2fc36feba8

Comment 15

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 16

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged

Comment 17

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Bug 2007200: make WebTransport exportKeyingMaterial args required and implement outputLength r=#webidl!,#necko-reviewers!,#dom-core!

Comment 18

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Bug 2007200: reject ExportKeyingMaterial's promise on failure instead of resolving with an empty array r=#dom-core!

Comment 19

[BugBot [:suhaib / :marco]]

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)

Comment 20

[Phabricator Automation]

Comment on attachment 9626051 [details]
Bug 2007200: reject ExportKeyingMaterial's promise on failure instead of resolving with an empty array r=#dom-core!

Revision D318354 was moved to bug 2063706. Setting attachment 9626051 [details] to obsolete.

Comment 21

[Hamish Willee]

FF155 MDN work for this can be tracked in https://github.com/mdn/content/issues/45216

Can I get a tehncial review of the doc part please: https://github.com/mdn/content/pull/45411

Specifically, I understand from https://github.com/w3c/webtransport/issues/411 that the mechanism allows an application level handshake to verify that two peers are on the same TLS connection. This stops replay attacks in the case where an MITM opens a connection to each peer and forwards between them, since the ends won't calculate the same exported material.

I think it doesn't prevent the MITM spoofing both endpoints, unless they have some other shared secret.
However with no "real world experience" would be good to get some independent technical eyes on this.

Comment 22

[Hamish Willee]

I can only assume I am right ^^^^. If I'm not let me know and we can fix up the docs as a post-process