Comment by superkuh

> QUIC REQUIRES CA TLS for all endpoints

No. QUIC require TLS. TLS just provides a way to move certificates, but doesn't care what a "certificate" actually is. JPEG of your 10m swimming certificate from school? Sure, that's fine.

The endpoints get to decide which certificates to accept and in practice in a web browser and many other modern programs that'll be some sort of X.509 certificate more or less following PKIX and on the public Internet usually the Web PKI which is a PKI operated on behalf of the Relying Parties (literally everybody) by the Trust Stores (in practice the OS vendors plus Mozilla for the Free Unix systems) but none of that is defined by QUIC.

Ok so you need to trust each other's certs. What's the big deal? Presumably you already have some other channel to share addresses so you can also share temporary self signed certs for this purpose.

A good time to mention that the P2P Yggdrasil network uses QUIC/TLS selfsigned certs but then runs its own encryption over that. You can add as many peers as desired, and the network will automatically choose the best path (latency). So no multi-pathing but gets around the issue of changing IP addresses/network locations. Plus, it's able to do multicast to find peers in your LAN without having a centralized control server. I'm actually getting better speeds than WireGuard over my LAN - but this is a stable link. Once you start sending the yggdrasil packets over long unstable links you may start to get into funky issues like TCP in TCP head of line blocking, but they try to mitigate this by having huge MTU sizes and packet dropping algorithms. (https://yggdrasil-network.github.io/2018/08/19/congestion-co...)

https://yggdrasil-network.github.io/documentation.html

I'm currently working on creating a managed Yggdrasil relay node service. A feature I hope they implement is QUIC multistream support.

What prevents you from just using certificates not signed by a CA and verifying them based on the public key fingerprint?

I'm working with QUIC in a personal project, while you can roll your own QUIC library the spec is large enough that it's quite a bit of work to implement it yourself. Most libraries allow you to pass in your own certificates. Realistically you could just bake in certs to your program and call it a day. Otherwise yes, you can implement your own cert logic that completely ignores certs altogether. s2n-quic for example specifically allows for both, though the former is much easier to do.

RFC 7250: Using Raw Public Keys in Transport Layer Security (TLS).

I guess most if not all QUIC endpoints you come across the internet will have encryption, as the specification requires as such. But if you control both ends, say you're building a P2P application that happens to use QUIC, I don't think there is anything stopping you from using an implementation of QUIC that doesn't require that, or use something else than TLS, even if the specification would require you to have it.

The existing WebTransport API implemented in all browsers actually supports you providing the fingerprint of a certificate that can be self-signed.