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.
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”
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.
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.
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.
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.