QUIC, Quinn & Crust: an update


Last question what about the censorship-resistance which was one of the main objectives of CRUST.

Are we now relying that since it is TLS it will become impossible to filter out the traffic from the “background noise” as a censorship resistance?
Wouldn’t the TLS handshake be fingerprintable?

Or there will be other measures added to ensure censorship-resistance?


Not impossible to censor but more difficult.

I am not sure it will, we will use the http traffic identifier and listen where we can on 443 etc. So hide in http traffic. Fingerprinting handshakes is going to be difficult unless agencies switch to whitelists. All in all this is harder to censor than a protocol we try from scratch to make it look like quic if that makes sense.


Btw, I found an interesting paper:
“0-RTT Key Exchange with Full Forward Secrecy”

Full Paper:

Edit: Digging a bit more I also found a presentation of the team on youtube:

Edit2: I just realized this is a very academic proof-of-concept, it is light years away to be practical to be implemented for TLS


lol I just found a new paper published this year (2019), made by some of the authors of the previous paper (published in 2017), this time they do talk about 0-RTT forward secrecy on TLS:
“Session Resumption Protocols and Efficient Forward Security for TLS 1.3 0-RTT”

Full Paper: https://eprint.iacr.org/2019/228.pdf


Has a decision been made about the use of keep-alive packets vs on-demand hole punching to solve the problem of dead sessions due to firewall UDP session timeout?


Hi Richard,

I’ve been reliably informed that:

Keep-alive is handled for us now, it is part of the quic spec and quinn implements that and we use quinn in quic-p2p. No hole punch yet.

Hope that helps.



Hi Dave,

I hope it is that easy.

As firewall udp session timeouts values can vary widely, it would be disappointing to find that the quinn implementation results in a very chatty network in order to accommodate the lowest common denominator.

I have experienced firewalls that do not handle udp as well as we might like (e.g. rate limitation, session table exhaustion).

You might have some tuning to do down the line to accommodate and potentially work around temporary and dynamically asymmetric P2P relationships.


Kind regards,



Not to mention household modems. Mine has to be restarted after a few hours (sometimes minutes!) of running bittorrent, probably because of the latter of those causes as DNS queries (UDP) stop passing through the modem.


Ah yes the maximum connections problem of home routers. Even had this problem with a business (isp supplied) fibre modem/router that would not allow web browsing at times on the Bosses computer. It turned out that the modem/router had a low maximum connection limit (for a business) and that the ISP only supplied the home style modem/routers. What caused this was that they allowed the workers free internet via the WiFi hot spot and one group of the young workers were social media etc all day and using up the connection capacity. No issues with bandwidth just maxing out connections. They solved it by not allowing the workers access via the WiFi


Not to go too far off topic, but if you haven’t already, you might want to consider subscribing to a VPN service. Then it doesn’t matter if your ISP has a low connection limit or ability to fulfill DNS requests - all of that now gets tunneled. I use one myself for virtually all of my Internet traffic (I configured my DD-WRT router to handle the OpenVPN connection).

One small downside is that it acts like a NAT with no possibility of port forwarding. But I assume that quic-p2p hole punching could potentially work around this, once developed.


A general question: When adopting new libraries like this, does Maidsafe check for risks of parts being covered by IP from Google or parties?


As much as possible, but we do not do patent searches on all parts as it would be prohibitive. The licence is best choice, if there were problems we can swap those libs out. No probs so far and several implementations of quic exist, so we have options there as well. Package managers mean you have many dependencies and while they are great, there are issues as well. IP is one, bugs is another as well as securing these. There is a great tool called cargo-vendor to lock deps in our repo and such like. Right now it is a continuous workload.


Hello there,
I am wondering if at some point in the future it is planned to integrate parts of Crust on Quinn (or viceversa, Quinn on Crust)

I know it is not priority right now and that it is technically not essential, but my nerdy side misses the random multi-port / multi-protocol and hole-punching ninja aspect of the library.


Some interesting insights about Uber implementing the QUIC protocol. Sounds like a good choice! :slight_smile:


1 Like

quic-p2p has replaced crust. I think it makes sense that there is a p2p specific part for now. There are moves to include much of that in quic though (check the network for quic p2p capabilities). Bootstrap cache and more though is a slightly bigger story, so I think options will become clear as we go on.

1 Like