Re: [quicwg/base-drafts] Request forgery attacks (#3995)

[Kazuho Oku <[e-mail]>]

@martinthomson Thank you for raising the issue.

I agree that NEW_TOKEN tokens and SPA are concerning. At the same time, I am not sure how much we have to worry about the encrypted payload being used as the attack vector.

> Therefore, frames carrying application data offer the attacker the means of indirectly controlling large portions of plaintext.

1-RTT packet protection key that is being used for encrypting the frames is *not* controlled by the attacker. The key is derived from the input of both endpoints. I am not sure how practical it would be to assume that a rouge server can calculate what the corresponding plaintext would be for an encrypted text that it wants to use for the attack, when the encryption keys are not obtained until the handshake is performed.

Regarding the amount of effort we should be spending to address this issue, I would point out that SSRF as we know today can induce a browser to send two types of TCP messages: 1) HTTP GET request (or preflight), 2) first flight of TLS over TCP.

I think we can call close the issue if we can make certain that the QUIC packets that the browsers send is as controlled as either of the two patterns.

Encrypted data meets the 2nd requirement. QUIC Initial packets are roughly as random and as binary as Client Hello of TLS over TCP. Encrypted part of QUIC packets are random and as binary as 0-RTT records of TLS over TCP.

Therefore, I think what we need to discuss is limited to NEW_TOKEN tokens and the DCID of SPA.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3995#issuecomment-673325577