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

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

Thanks @toreini for the positive general assessment! But I suspect some misunderstandings in the specific feedback:

> It is unclear whether the certificate hash digest is used for authentication ...  it seems the digest serves as proof of certificate ownership for an already established channel ... **Fallback** ... resent until verification completes at the server-side through the same established TLS session.

This sounds like a separate authentication step layered on top of a connection that already exists, with some retry behavior when it fails...

But [serverCertificateHashes](https://w3c.github.io/webtransport/#dom-webtransportoptions-servercertificatehashes) is not that. It's an option to the TLS [connection being created](https://fetch.spec.whatwg.org/#create-a-connection) in the first place:
- _"If webTransportHashes [is not empty](https://infra.spec.whatwg.org/#list-is-empty), instead of using the default certificate verification algorithm, consider the server certificate valid if it meets the [custom certificate requirements](https://w3c.github.io/webtransport/#custom-certificate-requirements) and if [verifying the certificate hash](https://w3c.github.io/webtransport/#verify-a-certificate-hash) against webTransportHashes returns true. If either condition is not met, then return failure."_

The server doesn't verify the hash — the client does. In TLS authentication, the client checks the server's certificate. The hash just replaces the trust-anchor on the client side.

Its value (and risks) have been discussed at some length already in https://github.com/w3c/webtransport/issues/623. But TL;DR:

The only substantive difference between this and a certificate is that a certificate can be revoked. But, because hashes are downstream of another certificate that can be revoked (the one issued to the site that is making the WebTransport session), the change in risk profile seems tolerable. All of the other things that people tend to think are problems with hashes in this context don't apply, because the client is still entirely dependent on the site that initiates the session. The site is equally capable of spinning up a new DNS name for this, which could be hosted just about anywhere. The advantage of the hash is real: the site doesn't need to get a certificate, which adds real latency to the setup of on-demand services.

This has passed two previous TAG reviews https://github.com/w3ctag/design-reviews/issues/669 https://github.com/w3ctag/design-reviews/issues/389, even before we added CSP support. https://github.com/w3c/webappsec-csp/pull/791

> Given the bi-directional nature of communication, authentication could benefit from a bi-directional approach. While the state-persistence approach (relying on TLS session tickets) is fair, certificate verification errors could make client authentication (and state persistence) non-deterministic

This is server authentication, not client authentication. HTTP is also bidirectional, but we have a well-established one-sided authentication model at the TLS layer.  This relies on exactly the same arrangement.

> The discussions on side-channel passive fingerprinting based on WebTransportConnectionStats are a reasonable starting point. However, the TAG encourages you to explore more privacy-preserving approaches for presenting fine-grained stats. For example, adopting a tier-based nomination of quantities...

This is being addressed with https://github.com/w3c/webtransport/pull/764 and https://github.com/w3c/webtransport/pull/766. PTAL.

The spec could perhaps be clearer about the fact that these stats are things that the server (which is explicitly chosen by the site and is directly aware of the identity of the site when accepting a connection) can measure.  The stats API only makes it easier for sites to gather the information. We can add text clarifying that the server already has this info.

Tier-based quantization wouldn't change that, because it'd quantize the client-side copy while the server keeps the full-resolution original.

Please let us know if this clarifies, or if you have other questions.

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

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