quic.md: add initial draft of QUIC transport

[fjl]

No description provided.

[MarcoPolo]

To be clear, this refers to RFC 5705, correct?

[healthykim]

Yes

[MarcoPolo]

Suggested change

	non-browser implementations should also verify the presented certificate upon connection
	non-browser implementations MUST verify the presented certificate upon connection

[MarcoPolo]

what's the ALPN?

[healthykim]

what's the ALPN?

h3 😎

[sukunrt]

Will we run http3 request / response etc on this? Or is it so that we can upgrade to webtransport?

[sukunrt]

Will the server verify the dialers public key?

[sukunrt]

StreamIDs depend on which side initiates them. https://www.rfc-editor.org/rfc/rfc9000.html#section-2.1

Should we mention the specific id we expect and the stream type?

[healthykim]

Will we run http3 request / response etc on this? Or is it so that we can upgrade to webtransport?

Not for request/response here. We will use it only for the Extended CONNECT that upgrades to a WebTransport session, everything after that is raw devp2p framing over the stream, as far as I think :)

[raulk]

What's the benefit of sending the ENR key binding over the first stream, instead of during the handshake as a PKIX extension, like libp2p does today?

This adds complexity to the connection state machine, which may require special casing and careful design for connection resumption scenarios, e.g. does a token remain valid after an ENR changes? On resumption, do we still exchange bindings? If yes, this adds 1-RTT before data can be exchanged. If no, the resumed connection would have downgraded security (the node backing that QUIC endpoint could've been replaced by another ENR identity, and we wouldn't notice).

I like the omission of a PKIX extension because it's makes it harder to identify an Ethereum node "at face value". But in practice, the argument doesn't stand because: (a) ENR records are public, and (b) at this connection stage there is no evidence or information that would lead a node to withhold its ENR, so it seems non-optional to send it.

[healthykim]

What's the benefit of sending the ENR key binding over the first stream, instead of during the handshake as a PKIX extension, like libp2p does today?

This adds complexity to the connection state machine, which may require special casing and careful design for connection resumption scenarios, e.g. does a token remain valid after an ENR changes? On resumption, do we still exchange bindings? If yes, this adds 1-RTT before data can be exchanged. If no, the resumed connection would have downgraded security (the node backing that QUIC endpoint could've been replaced by another ENR identity, and we wouldn't notice).

I like the omission of a PKIX extension because it's makes it harder to identify an Ethereum node "at face value". But in practice, the argument doesn't stand because: (a) ENR records are public, and (b) at this connection stage there is no evidence or information that would lead a node to withhold its ENR, so it seems non-optional to send it.

Yeah, I agree that the resumption case is not specified well enough. If we were considering only node-to-node connections, using a PKIX extension would make much more sense.

The main focus of this draft is browser connectivity though (which is not clear enough in the current document yet, I'm working on making that more explicit). The authentication mechanism needs to be compatible with WebTransport, which means that identity verification should be possible using the WebTransport APIs. That is the main reason for keeping the identity binding outside the TLS certificate (I guess, felix could have more reasons).

I think we also don't expect long-lived session resumption as a primary requirement for browser connections. However how to unify the node-to-node and browser connection is still not very clear to me. Just for now I think the priority of this draft is to make the browser connection possible.

[raulk]

Ah I see, that context changes things. I'd be interested in learning more about the browser-side assumptions. More concretely: are you designing for the consumer to be a website directly, or will there be a browser extension mediating? (wallet style). If we expect the latter, I'd highlight that both Chrome and Firefox offer public APIs to inspect the X.509 extensions in a certificate: https://developer.chrome.com/docs/extensions/reference/api/webRequest?utm_source=chatgpt.com#type-SecurityInfo.

[healthykim]

Ah I see, that context changes things. I'd be interested in learning more about the browser-side assumptions. More concretely: are you designing for the consumer to be a website directly, or will there be a browser extension mediating? (wallet style). If we expect the latter, I'd highlight that both Chrome and Firefox offer public APIs to inspect the X.509 extensions in a certificate: https://developer.chrome.com/docs/extensions/reference/api/webRequest?utm_source=chatgpt.com#type-SecurityInfo.

Hmm... I've been thinking about this more, but doesn't this prove essentially the same thing as qh?

What we want from the identity proof is to know whether the server we're connected to right now actually holds the same node key we expected from the ENR. Both qh and a PKIX extension only prove that the node key authorized the certificate before, and they don't prove that the peer holds that node key in this particular session. I am not sure how libp2p is dealing with this, would like to check later.

On top of this qh is required anyway for certificate pinning in WebTransport. AFAIK the browser can only trust a self-signed certificate if the certificate hash is provided in serverCertificateHashes.