How is this attack different from initiating a new TLS handshake, as the server will also use secure random in that case?
On Thu, Oct 29, 2020 at 19:04 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 > > >
