Implement QUIC

[tomaka]

Create a QuicConfig<T> struct.

Since we require the underlying transport to be UDP and UDP operates on individual packets of data and not a stream, T::Output should implement Stream<Bytes> + Sink<Bytes> (or something similar to Bytes) instead of AsyncRead + AsyncWrite.

QuicConfig itself should implement Transport and its Output should implement StreamMuxer.

[tomaka]

Consider https://github.com/djc/quinn

[tomaka]

Linking this here in case it's useful: https://youtu.be/EHgyY5DNdvI

[tomaka]

Since QUIC is purely UDP, and UDP cannot be used from within a browser, this issue is lower priority than an equivalent multiplexing protocol for TCP.

[burdges]

There are security considerations in using QUIC which Adam Langely discussed in his RWC 2017 talk. I do not see any good links right now, but this might point the right direction : https://security.stackexchange.com/questions/123656/is-the-quic-protocol-secure

[eira-fransham]

@burdges That's a shame, although our current multiplexing implementation is laughably DoS-able

[burdges]

There is a discussion that clarifies matters here, including a paper link.
https://groups.google.com/a/chromium.org/forum/#!topic/proto-quic/S5KkNjK4EUQ
There are also specific considerations when used which RSA about which do not impact libp2p afaik. Anyways TLS 1.3 has a good security proof.

[tomaka]

Related: https://eprint.iacr.org/2019/028

[burdges]

I'll check that out eventually. Ideally I should check if the noise handshake they select fix the issue with the key exchange Adam Langely initially selected, probably fine.

We could get someone to add Rust to https://noiseexplorer.com too btw.

[burdges]

There is a thread on [email protected] in 2018 on nQUIC with relevant messages being https://moderncrypto.org/mail-archive/noise/2018/001930.html and the thread starting form https://moderncrypto.org/mail-archive/noise/2018/001933.html

There is some contention over nQUIC focusing on IK so that's maybe a shortcoming.

[tomaka]

For reference, here's what libp2p is doing for TLS 1.3: libp2p/specs#151

In Rust we have a lot of problems:

• Rustls forbids self-signed certificates, so we have to use the "dangerous" verifier. However I would say that this fine.
• We don't have any library to generate certificates except rcgen and openssl. rcgen is too limited but could be improved. openssl is too heavy.
• We need to know the content of the remote's certificate in order to extract its public key. However the API of rustls doesn't allow doing that, except within the custom certificate verifier. This means that the verifier has to store the decoded public key in some Arc<Mutex<>> so that the "outside" can later retrieve it. This is probably very problematic, especially in an area as sensible as crypto where you don't want to accidentally report the wrong public key.
• openssl allows decoding certificates, but doesn't allow reading extensions. We need to decode DER/ASN.1 with a different crate.

I would suggest picking a DER/ASN.1 crate and doing the certification generation and verification ourselves. I don't have any real solution for rustls, except asking for that feature.

On the side of QUIC there are some other issues:

• The quinn-proto library is agnostic over I/O, but doesn't support multiple UDP sockets. You're supposed to feed data that you read on "the" socket to the library, and later obtain back the list of connections that have been opened. There's no way to know which connection belongs to which socket.
• Generally, QUIC would use one single local port for all the dialing and listening. What this means is that if the user tries to connect to a remote, we would use the same local port as the one we're listening on. However, if the user starts by dialing a remote before listening, which source port would we use? This probably has to be passed in the configuration.

We could solve both QUIC issues by enforcing one single address/port in the configuration for QUIC, and only allow listening on this specific address/port combination.

[Demi-Marie]

@tomaka QUIC only requires one socket each for sending and receiving.

[tomaka]

cc #1334

[mxinden]

Closing here in favor of #2883.