18 Aug 2024
QUIC is an encrypted control protocol. That’s a big difference with TCP, and it prevents some of the known attacks against TCP, such as a third party sending a TCP “Reset” packet (RST) and closing a TCP connection. In QUIC, the equivalent of the RST packet would be a “Connection Close”. It will only be accepted if sent inside an encrypted packet, and once the connection is established only the two end points can send that. But there is a catch. The cryptographic keys are negotiated during the TLS handshake carried in the initial packets. These packets are encrypted, but the encryption key is a function of the initial connection identifier and the QUIC version number. We can thus have the following scenario:
In practice, this looks a lot like the RST attack against TCP, the main difference being that the attacker has to be quick – if Bob’s response arrives before Eve’s message, the attack will fail. This is not a new attack that I would just have discovered. It was discussed at length during the standardization of QUIC. There is in fact a whole class of such attacks – Eve could use Version Negotiation packets, Retry packets, spoofed Client Hello packets, or packets that contain a protocol error. Eve could also send the sppofed packets to Bob, such as a “connection close” packet that arrives after Alice’s first message but before Alice’s response to Bob’s initial message. Fixing all that was deemed too difficult, and so RFC 9001 merely states that “After completing the TLS handshake, the client will have learned and authenticated an identity for the server, and the server is optionally able to learn and authenticate an identity for the client.”
Back in 2019, Kazuho Ohu and I proposed an [Authenticated Handshake for QUIC] (https://datatracker.ietf.org/doc/draft-kazuho-quic-authenticated-handshake/). The idea was to use a shared secret established before the connection to authenticate the Initial messages, and prevent third parties from injecting spoofed messages. The draft is now expired, maybe because the requirement to share secrets before the connection was not practical. There were later attempts to use the Encrypted Client Hello to establish a shared secret and protect the handshake, but that too did not work because the ECH derived secret is only available to late to protect the first initial packets. Overall, it seems that protecting the QUIC handshake is one of those ideas that comes up periodically and always fails to attract traction, maybe because we have not seen much of these RST-style attacks yet so there is no urgency. But I would rather see development of security before the attacks rather than after them.
Maybe it is time to revisit these old drafts, and come up with a robust solution that does not require shared secrets at all.
If you want to start or join a discussion on this post, the simplest way is to send a toot on the Fediverse/Mastodon to @huitema@social.secret-wg.org.