Contact emails [email protected], [email protected]
Explainer https://github.com/w3c/webtransport/blob/main/explainer.md Specification https://www.w3.org/TR/webtransport/#dom-webtransport-exportkeyingmaterial Summary Adds WebTransport.exportKeyingMaterial(), which allows an application to derive cryptographic keying material bound to an established WebTransport session. The method accepts application provided binary label and context values and a requested output length and returns a Promise<Uint8Array>. Chromium supports label and context values up to 255 bytes and output lengths from 1 through 4096 bytes. For WebTransport over HTTP/3, Chromium includes the WebTransport CONNECT stream ID in the TLS exporter context. This ensures that separate WebTransport sessions derive different keying material even when they share the same underlying HTTP/3 connection. Blink component Blink>Network>WebTransport Web Feature ID webtransport Motivation Applications sometimes need cryptographic keying material bound to an authenticated transport session, for example to bind an application protocol, authentication exchange, or application-level encryption context to a WebTransport session without performing an additional key exchange. TLS exporters derive application-specific secret material without exposing the TLS traffic keys. WebTransport.exportKeyingMaterial() exposes this mechanism through application-provided binary label and context values and an explicit output length. Multiple WebTransport sessions can share one HTTP/3 connection. Chromium therefore includes the WebTransport CONNECT stream ID in the exporter context, ensuring that different sessions derive different keying material even when callers use identical application labels and contexts. Initial public proposal https://github.com/w3c/webtransport/issues/411 TAG review This is an incremental method within the existing WebTransport specification. WebTransport has an umbrella TAG review, and a separate feature-level review is not currently planned. TAG review status Not applicable Goals for experimentation None Risks Interoperability and Compatibility Interoperability risk: Medium. The current WebTransport specification and upstream WPT define the required three-argument exportKeyingMaterial(label, context, outputLength) method. Chromium and WebKit implement this shape. Firefox currently exposes the earlier two-argument form without outputLength , so API-shape interoperability is not yet complete. Implementations and servers must also use the same fixed exporter label and exporter-context construction, including the WebTransport session ID, application label, application context, and requested output length. A mismatch produces different bytes without an explicit protocol error. Compatibility risk: Low. The method is additive and does not change existing WebTransport construction, streams, datagrams, or connection behavior. Applications can use feature detection with "exportKeyingMaterial" in WebTransport.prototype. Gecko: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=2079306) Firefox is updating its implementation to the current three-argument API. WebKit: In development (https://github.com/WebKit/WebKit/pull/69982) WebKit has landed an implementation of the current three-argument WebTransport.exportKeyingMaterial(label, context, outputLength) API. Web developers: Positive (https://github.com/w3c/webtransport/issues/411) The proposal received 10 👍 reactions and requests from developers, including libp2p, for TLS-session binding and channel-binding use cases. Other signals: Ergonomics Ergonomics risk is moderate because this is a low-level cryptographic primitive. Binary BufferSource label and context values avoid string-encoding ambiguity, while the explicit output length avoids an implicit key-size choice. Calls made while the WebTransport session is connecting are queued until the connection is established. Calls after closure or failure reject with InvalidStateError . Label or context values over 255 bytes and zero or unsupported output lengths reject with RangeError . Documentation should recommend protocol-specific domain-separation values and secure handling of the resulting bytes. Activation Activation risk is moderate but bounded. The API is additive and has no effect unless a site explicitly invokes it. It introduces no new network messages or additional protocol negotiation. The main activation risk is a mismatch between client and server implementations in the exporter construction, including the fixed exporter label, WebTransport session ID serialization, application label or context, and output length. Such a mismatch causes the endpoints to derive different bytes without an explicit error. Chromium mitigates this risk through validation in Blink and across the renderer/network-service boundary, fixed input limits, session-specific domain separation, lifecycle checks, unit and Web Platform Tests, and the WebTransportExportKeyingMaterial runtime/Finch feature gate. Security This API exposes secret-derived material to script and therefore requires careful domain separation and lifecycle handling. It does not expose TLS traffic keys or allow callers to decrypt WebTransport traffic. Chromium uses the fixed TLS exporter label "EXPORTER-WebTransport" and constructs an exporter context containing the WebTransport CONNECT stream ID, application label, and application context. Including the CONNECT stream ID prevents different WebTransport sessions sharing one HTTP/3 connection from deriving identical keying material when given the same application inputs. Chromium limits label and context values to 255 bytes and output to 4096 bytes, validates requests in both Blink and the network service, verifies the returned output length, and rejects calls after the session has closed or failed. Applications remain responsible for treating the result as secret keying material and using protocol-specific label and context values Security questionnaire: https://github.com/w3c/webtransport/blob/main/security-questionnaire.md 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? Low. This is an additive API implemented in shared Blink and network-service code. The CL updates the Android WebView Web-exposed interface expectation and requires no WebView-specific integration. Stable WebView exposure should follow the existing availability and launch process for WebTransport in WebView. Debuggability Developers can inspect the label, context, output length, returned Uint8Array, and any rejected exception through JavaScript breakpoints or the Console. CDP exposes WebTransport creation, connection-establishment, and closure events. NetLog provides additional WebTransport version, QUIC lifecycle, and stream diagnostics. Neither CDP nor NetLog records exporter invocations, exported bytes, or compares the client-derived value with the server-derived value. A client/server derivation mismatch therefore requires server cooperation, preferably through a key-confirmation challenge or MAC rather than logging raw keying material. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? Yes All Blink platforms on which WebTransport over HTTP/3 is supported. The Web-exposed implementation is cross-platform Blink code, while key derivation uses Chromium's existing HTTP/3/QUIC TLS exporter path. Is this feature fully tested by web-platform-tests? Yes https://wpt.fyi/results/webtransport/export-keying-material.https.any.html?label=experimental&label=master&aligned, https://wpt.fyi/results/webtransport/idlharness.https.sub.any.html?label=experimental&label=master&aligned Flag name on about://flags chrome://flags/#enable-experimental-web-platform-features Finch feature name WebTransportExportKeyingMaterial Rollout plan Will ship enabled for all users Requires code in //chrome? False Tracking bug https://issues.chromium.org/issues/556304550 Measurement Measure correctness and interoperability through Web Platform Tests, the WebTransport IDL harness, wpt.fyi results, and feedback from WebTransport application and server implementers. Usage will be measured with a WebFeature use counter recorded when WebTransport.exportKeyingMaterial() is called. No dedicated UMA metric is currently planned, the use counter is sufficient to measure web-exposed API adoption Availability expectation Expected to become available across major browser engines as part of the W3C WebTransport specification. WebKit has landed the current three-argument API in WebKit main, although stable Safari availability has not yet been verified. Firefox currently implements the earlier two-argument form without the required outputLength argument. Adoption expectation Expected to be used by specialized WebTransport protocols that require transport-bound authentication, channel binding, or application key derivation. It is not expected to be used by most basic WebTransport applications. Adoption plan Adoption is expected to occur through WebTransport documentation, interoperable WPT coverage, and use by protocol implementations that require transport-bound keying material. No origin trial or broad developer campaign is currently planned Estimated milestones Shipping on desktop 158 Shipping on Android 158 Shipping on WebView 158 Anticipated spec changes Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (eg links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (eg, changing to naming or structure of the API in a non-backward-compatible way). No API-shape changes are currently anticipated. Chromium implements the current required three-argument method and matches the WebTransport-over-HTTP/3 exporter construction, including the fixed exporter label and session-specific context encoding. https://github.com/w3c/webtransport/issues/791 tracks making the specification's reference to the protocol-level exporter construction more explicit. This is currently an editorial clarity issue rather than a known behavior change. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/4860330806214656?gate=6662931365363712 Links to previous Intent discussions Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6aa97628.f13237a8.13ec.001a.GAE%40google.com This intent message was generated by Chrome Platform Status. -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ad90dd7.a6e82b8f.de7e0.0240.GAE%40google.com.
