And that also answers my worry about how the site-provided label is made to conform to the requirements from TLS. Thanks!
Jeffrey On Tue, Sep 15, 2026, 2:45 PM Martin Thomson <[email protected]> wrote: > Good catch there. The specification doesn't directly point to the > concrete requirements, because of the way that webtransport is > architected. The API spec references the overview, which only > indirectly describes the functions that specific concrete versions of > the protocol implement. > > https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3#section-4.8 > describes what to do when HTTP/3 is used, which does exactly as Adam > describes. That's probably worth some effort to address, because it's > easy to reach a bad conclusion. > > (In other words, Adam's choice of wording here might have been > unfortunate, but there's no funny business going on.) > > On Wed, Sep 16, 2026 at 7:34 AM Jeffrey Yasskin <[email protected]> > wrote: > > > > On Tue, Sep 15, 2026 at 9:45 AM Chromestatus < > [email protected]> wrote: > >> > >> Contact emails > >> [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. > > > > > > Quick question. My understanding is that, in order for this to work, > both ends of the TLS session need to compute the same keying material. > Since the other end won't be a Chromium browser, I'm worried to see > "Chromium includes" here, rather than a reference to a standard that > defines how to include that stream ID. The spec seems to just say "Let > keyingMaterial be a Uint8Array that is produced by invoking a TLS key > exporter, as defined in [WEB-TRANSPORT-OVERVIEW] Section 4.1, with label, > context, and outputLength.", which doesn't say how to combine the stream ID > into the context. > > > > Are y'all working on tightening this specification, or have I missed a > place where it actually is already rigorous? > > > > Thanks, > > Jeffrey > > > > > >> > >> 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 > >> > >> Goals for experimentation > >> None > >> > >> 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. Firefox has implemented an earlier > two-argument version of the method but has not yet been verified as > supporting the current required three-argument signature. No WebKit > implementation of this specific method has been verified. > >> > >> 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 > >> > >> No milestones specified > >> > >> > >> > >> 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). > >> > >> No API-shape changes are currently anticipated. Chromium implements the > current required three-argument method from the WebTransport Candidate > Recommendation. The protocol-level exporter construction should be > rechecked against the referenced WebTransport overview specification before > stable launch. > >> > >> Link to entry on the Chrome Platform Status > >> https://chromestatus.com/feature/4860330806214656?gate=4833344016744448 > >> > >> 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/6aa97628.f13237a8.13ec.001a.GAE%40google.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 [email protected]. > > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dX%3DNUD4JbGQXkje4%2BffTtcpv6Srn8MkxrGA-LJu%3DK-Y6tQ%40mail.gmail.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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dX%3D2jWo2H%2BQ-tPBK6ZF4WOn-hVawz_otL%3DdwsDf-e682pg%40mail.gmail.com.
