Our firewall currently blocks QUIC (UDP 443) traffic which seems to be enabled by default in Google Chrome. Is it safe to allow QUIC or should I wait until it is implemented in all the major browsers?
I understand that it's been developed as an experimentation by Google aiming to enhance web application performance.
QUIC by itself is no more dangerous than TCP, UDP, HTTP ... . What matters is the content transferred with the protocol. If you use your firewall only as a simple packet filter and don't do any content inspection (i.e. malware, URL filter etc) then it does not matter much if you allow QUIC or not. If instead your firewall is used to analyse HTTP(s) traffic than it might be a good idea to drop QUIC traffic so that the browser will continue to use HTTP(s) and not bypass the analysis with a protocol your firewall does not understand.
Update February 9, 2019: Source: New TLS encryption-busting attack also impacts the newer TLS 1.3
"Seven researchers from all over the world found --yet again-- another way to break RSA PKCS#1 v1.5, the most common RSA configuration used to encrypt TLS connections nowadays. Besides TLS, this new Bleichenbacher attack also works against Google's new QUIC encryption protocol as well."
======================================================
Previous comment: "Attacks can be used to deny clients access to any application of choice and cause servers to waste resources!" As of now, not particularly dangerous. Everything noted below only can cause denial of service (connection) and broken connections, thats about it.
https://www.ietf.org/proceedings/96/slides/slides-96-irtfopen-1.pdf
QUIC uses 0-rtt (session resumption / tickets) which is potentially vulnerable to replay attacks, as noted here; so does tls; tls 0-rtt can be disabled in firefox, though I'm not sure if there are options to disable 0-rtt for quic in browsers at this time. After a little further digging even quic 1-rtt (connection handshake) is/was (2015 as of the time of the article) vulnerable to MITM as well, Server Config Replay Attacks, Source-Address Token Replay Attacks and Packet Manipulation Attacks:
We target the Chromium implementation of QUIC7 in our attacks, as this is the canonical implementation. Our attacks were developed in python using the scapy library. We summarize our attacks, their properties, and impacts in Table 1. Replay Attacks. Server Config Replay Attack. To conduct this attack, an attacker must first collect a copy of the target server’s scfg. This can be done either by actively establishing a connection to the server or by passively listening for a client to attempt a connection. In either case, the server’s scfg can be readily collected from a full, 1-RTT QUIC connection handshake. Once the attacker has scfg, he waits for the target client to attempt to start a connection. When the attacker sees a c hello message from the client, he can respond with a spoofed srejectmessage using the collected scfg and randomly generated stk and sno values:
SRC https://eprint.iacr.org/2015/582.pdf
Mind you the article was writ back in 2015 and the protocol has likely evolved since then.
I agree with Steffan that QUIC is no more dangerous than TCP or UDP or HTTP or any other communication protocol. I think for your use case what really matter is the data being transferred through the protocol.
Like Steffan said, it really depends on the firewall and the concerns you are trying to address using that firewall. Doing an informal threat modeling (what kind of attacks/threat actors are your major concern? what kind of assets are you trying to protect using the firewall?) and sharing some of your specific concerns in the questions with regards to QUIC would actually help others to provide definite answers.
Talking about security of the protocol itself - I'm no expert in protocol security, but based on my understanding, all the communication protocols go through a lot of scrutiny from Security Researchers and Experts before being declared as a standard (usually through RFCs). With this regards, QUIC is not as mature as TCP or UDP or HTTP, but there has been a lot of security research done around the protocol.
The most relevant research I was able to retrieve is How Secure and Quick is QUIC? Provable Security and Performance Analyses - By Lychev et al. The authors basically introduce a security model for analyzing performance-driven protocols like QUIC and prove that QUIC satisfies their definition under reasonable assumptions on the protocol’s building blocks.
