Filippo Valsorda

Wow, QUIC Retry Packets use AES-GCM with a fixed key/nonce, empty plaintext, and associated data prefixed with a secret as a sort of MAC. That's... terrifying?

They essentially do MAC(K, v) = AES-GCM(key=const, nonce=const, plaintext=empty, aad=K||v). Does that actually hold?

https://quicwg.org/base-drafts/rfc9001.html#section-5.8

RFC 9001: Using TLS to Secure QUIC

This document describes how Transport Layer Security (TLS) is used to secure QUIC.

Nov 24 at 10:51amWeb
Show threadHenryk PlötzNov 24
@filippo Ahh, the old adage of "If all you have is a hammer, make sure it's a damn good hammer." or something.
Show threadDennis JacksonNov 24

@filippo I don't think a MAC is the right model since the key+nonce is public and fixed - more akin to a hash function chosen from a family of PRFs. MAC CCA security doesn't apply (since key is known). MAC Committing security is too strong (since key is fixed / not attacker controlled).

So it's more akin to whether GCM with a fixed public key and nonce is first/second pre image resistant? Even if not, it still retains some security provided the function image is large enough.

Show threadDennis JacksonNov 24
@filippo Thinking through the scenario with retry packets and on/off path attackers, I think it's only the latter, v. weak notion of security that is needed.
Show threadFilippo ValsordaNov 24

@dennisjackson The RFC claims that knowledge of the original connection ID is needed to forge packets, so the actual "MAC key" is the OCID. Ignore the actual GCM fixed key.

The OCID is just a prefix of the packet, so essentially the RFC claims that GHASH(K || v) is a MAC, which it is definitely not.

However, I generally agree that retry packets don't really need a MAC, so I think it's just a case of the RFC making too strong a claim, not of anything being broken in practice.

Show threadasanteNov 24
@filippo I think it is reversible and thus, the retry pseudo packet can be reconstructed (or at least a linear combination of the aad blocks, b/c as I understand the RFC, the retry pseudo packet would be longer than one AES block).
But what I don't get is: what is the actual secret in the retry pseudo packet?
Show threadbkkNov 24
@filippo @matthew_d_green