Anybody who has the ticket and therefore has the public key can connect.

Once connected, the connection is encrypted using TLS with the raw public keys in TLS extension ( https://datatracker.ietf.org/doc/html/rfc7250 ).

▲

trklausss 5 days ago | parent [-]

So if it single-point, there will be a really small window where someone could try to brute-force it (almost impossible, I know), but if it is multi-point (i.e. multiple users can connect to that endpoint) then it could be brute-forced and connect to it? I couldn't see if it is single-point of multiple-send...

Let me know if my understanding is incorrect, I don't have much experience with QUIC :)

	▲	rklaehn 4 days ago \| parent [-]
		I am not one of the cryptographers on the team, but I will try to answer to the best of my knowledge. QUIC is specifying TLS, specifically TLS 1.3 or larger. From the RFC 9001 (Using TLS to Secure QUIC): "Clients MUST NOT offer TLS versions older than 1.3.". For the first request, brute forcing would mean guessing a 32 byte Ed25519 public key. That is not realistically possible. For subsequent requests, even eavesdropping on the first request does not allow you to guess the public key, since the part of the handshake that contains the public key is already encrypted in TLS 1.3. With all that being said, if you want to have a long running dumbpipe listen, you might want to restrict the set of nodes that are allowed to connect to it. We got a PR for this, but it is not yet merged. https://github.com/n0-computer/dumbpipe/pull/68