Re: [quicwg/base-drafts] Amplification attack using retry tokens and spoofed addresses (#2064)

[Marten Seemann <[e-mail]>]

@huitema 
>  if I recall correctly, there was an intense discussion about 0-RTT and session ticket reuse in the TLS working group. Some forms of 0-RTT replay attacks can be prevented if session tickets are used at most once, or at least if session tickets enable 0-RTT data at most once per use. That discussion showed that at-most-once was very hard to handle in a big server farm, as it would require centralized management of state across many servers. See section 8 of RFC8446, "0-RTT and Anti-Replay" for the resulting compromise.

I think we're talking about different security properties here. QUIC tokens are designed to **only** prove reachability at a specific IP address, and don't contain any sensitive information beyond that. Token reuse is therefore only a problem **if** it can be used by an attacker to flood the client with more unwanted traffic than either the client or the network can handle at any given time.

@kazuho
>> I don't a short token life time works as a protection here. I expect servers to issue tokens (in NEW_TOKEN frames) that have the same life time as TLS session tickets, which, if I remember correctly, is a 7 days.
>
> I am not sure if that's correct. IIUC, the reason we split information that are maintained across connections to TLS session tickets and tokens was because they have different properties, including lifetime.

If I remember correctly, the reason we split those was to enable token validation without parsing of the packet contents and handing it off to the TLS stack. That being said, I think you're right that tokens might have a different life time than session tickets.
Since most (?) ISPs reassign a new IP address to the customers every 24 hours (at least that's how they typically do it in Germany), a token would become worthless after this time. I'd therefore expect a NEW_TOKEN token to be valid for around that duration.

But even if this was not the case, and the token validity was just on the order of a minute, we'd have a problem here. An attacker who captures such a token can make the server send traffic with a high amplification factor to the client for the lifetime of that token.
This might even be a problem for Retry tokens, which will only be valid for a few seconds: If the attacker can cause a high load on the path to the client, it might succeed in creating enough congestion that the packets belonging to the actual handshake are dropped.

-- 
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/pull/2064#issuecomment-445423431