I think you make a good point. But there are other areas of equal concern that I no longer recall. The general QUIC consensus was that QUIC relies on a quality PRNG and if it is compromised, all bets are off anyway.
Even so, I don’t think it is a good idea to expose more PRNG state than necessary. Implementations are of course free to use their own discretion in this case. I believe the wording on appearing random is carefully chosen to allow so leeway here. QUIC could at most provide some additional recommendations. But then you could recommend a lot of things outside the core area of QUIC. Kind Regards, Mikkel Fahnøe Jørgensen On 29 October 2020 at 13.04.49, Florentin Rochet ( [email protected]) wrote: Dear QUIC designers, I've been recently following the discussion on PATH_CHALLENGE/PATH_RESPONSE attack scenarios, and for what it matters, I am also working on QUIC-like capabilities above TCP. In my design, upon thinking on connection migration attack vectors, I've been worried about another type of exploit. It is more critical in my opinion than bandwidth amplification, and it also affects QUIC. So, regarding QUIC, when a connection migration is initiated, from the current specification[0], "An endpoint can migrate a connection to a new local address by sending packets containing non-probing frames from that address." Sending a non-probing packet would trigger a PATH_CHALLENGE message from the other peer in an implementation following those specs to enter in path validation. Essentially, it means that a client can, on-demand, trigger a PATH_CHALLENGE from the server. In the specification[1], the PATH_CHALLENGE is containing an unpredictable payload. More formally, it is meant to be indistinguishable from the output of a random function. In practice, there are different ways to compute this "unpredictable" payload, with critical differences. The naive approach is to use unsecure randomness random(), and then putting it in the PATH_CHALLENGE. Another approach would be to use secure randomness to satisfy the current specifications. That is, putting the output of SecureRandom() to the PATH_CHALLENGE. Ironically, the second approach is worrying me. That is, the current protocol specifications may provide incentives to implement a protocol channel to allow any client to query the server's PRNG output on-demand, and with probably a consequent amount of randomness bandwidth. We know from history that this is not a great idea, especially is the presence of potential weaknesses within the PRNG (intentional or not). The most appealing example is the backdoored Dual EC PRNG, for which the "backdoor holder" would only need to bruteforce 16 bits to recover the internal state and predict any new outcome. This is possible as soon as enough of the Duac EC output is observed. In the case of Dual EC, and assuming that the PATH_CHALLENGE contains 16 bytes of randomness, the attacker would only need to trigger 3 PATH_CHALLENGE to predict the PRNG's next outcomes (assuming P256 base points). Of course, Dual EC is an extreme case, for which the randomness could still be available from other protocol materials (e.g., ConnIDs or keys), but we should anyway avoid specifying a protocol that would offer Secure Randomness easily, and not under the peer's control. I suggest to specify what "unpredictability" means and how to compute it and iterate over multiple "unpredictable" payloads. A goal would be to make clear that we want as few as possible outputs from SecureRandom() to avoid for e.g., a client to have an oracle access to the Server's PRNG. A solution could be to use a simple Hash function and R, 16 bytes of randomness only known by the server and global to all sessions. Then a PATH_CHALLENGE could contain, with SESSION_SERCRET the shared derived secret of the session: Challenge_1 = H(SESSION_SECRET || R) Then, the next one: Challenge_2 = H(Challenge_1 || R) ... Challenge_i = H(Challenge_i-1 || R) This maintains unpredictability, assuming a cryptographic hash function and R secret. I guess that other constructions are possible as well, using HKDF for example. I would also suggest looking into other places for which "unpredictability" is needed, and evaluate whether it could provide good oracle access to the other peer, and if we can be more exigent into the specifications to make sure to avoid those issues. I have opened a issue to github to further discuss appropriate changes, if any are decided. https://github.com/quicwg/base-drafts/issues/4314 Best regards, Florentin [0] https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-transport.md#initiating-connection-migration-initiating-migration [1] https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-transport.md#initiating-path-validation
