Re: [w3ctag/design-reviews] WG Revision: WebTransport (Issue #1212)

toreini left a comment (w3ctag/design-reviews#1212)

Hi,

Thank you for the detailed and constructive response. It resolved the questions we raised. We've also reviewed the current Editor's Draft (3 July 2026) and are pleased to see the relevant changes have already landed. Summarising where things stand:

## 1. `serverCertificateHashes` and server authentication

We accept the clarification: the hashes are an input to the TLS connection-establishment step itself, replacing the default trust-anchor verification on the **client** side, and a verification failure simply fails the connection (per *"If either condition is not met, then return failure"*). There is no post-connection authentication step, no retry semantics, and no client-authentication implication, so our "fallback" and "bi-directional authentication" questions are withdrawn. We also note this mechanism was examined in our two earlier reviews ([w3ctag/design-reviews#389](https://github.com/w3ctag/design-reviews/issues/389), [w3ctag/design-reviews#669](https://github.com/w3ctag/design-reviews/issues/669)) and has since gained CSP integration ([w3c/webappsec-csp#791](https://github.com/w3c/webappsec-csp/pull/791)).

The revised spec now addresses the clarity gaps that led to our misreading:

- §14.4 *Server Authentication using Certificate Hashes* explains the Web PKI trust-anchor substitution, the second-preimage-resistance assumption, the revocation trade-off (including cache invalidation of provisioned hashes), the two-week validity limit rationale, and rotation via multiple hashes, capturing the analysis from w3c/webtransport#623 in-spec, as we'd hoped.
- §14.4 explicitly states this mechanism provides no client authentication, and §14.1 states certificate verification errors are fatal with no bypass.

* **One small remaining editorial suggestion:** the normative `serverCertificateHashes` definition (§6.9) could cross-reference §14.4, so readers of the API surface find the security rationale without needing to reach the considerations section independently.

## 2. `WebTransportConnectionStats` and fingerprinting

We're pleased to see concrete movement here, now reflected in the draft:

- w3c/webtransport#766 (merged) is realised in §6.13's "pooled connection stat" marking: counter-based stats (including all datagram stats) are normatively excluded from poolable connections in `getStats()`. Thank you.
- The §14.5 *Fingerprinting and Tracking* section includes the clarification you offered, that the server can observe this information directly through its own networking stack, so restrictions in user agents are not the only mechanism needed  along with the §14.5.1–14.5.3 breakdown of static observations, shared networking, and pooled sessions. This is a solid Privacy Considerations treatment.

We accept the point that quantising the client-side copy would not meaningfully reduce what the site can learn on dedicated connections, and consider our earlier tier-based suggestion superseded by the pooled-stats restriction, which addresses the sharper cross-context risk.

* **One remaining note:** we understand the pooling-partitioning tightening was resolved at the fetch layer (whatwg/fetch#1926, superseding w3c/webtransport#764). Since §14.5.3's statement that a network partition key disables risky pooling is non-normative and the guarantee lives in fetch, we'd encourage the WG to confirm the WebTransport spec's normative reliance on fetch's "obtain a connection" fully captures the intended behaviour once the fetch change lands, so the guarantee can't silently regress.

With that, we don't expect further substantive concerns from this review. 


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1212#issuecomment-5071009850
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1212/5071009850@github.com>