4 ms·

Am curious about QUIC and HTTP3 as well.

• janosdebugs 3y ago
  QUIC explicitly mentions that it is vulnerable to amplification attacks in the RFC. It suggests sending an extra packet to mitigate, at which point I believe the advantage of QUIC is lost as far as establishing connections is concerned.
  • johncolanduoni 3y ago
    I believe you're referring to the stateless retry mechanism? It's designed to be used only when the server is actually under attack (either as an amplification vector or exhaustion of its own connection capacity). The idea is that the server establishes some threshold for pending QUIC connections, and only if that is exceeded does it start requiring clients to complete the extra stateless, SYN-cookie style roundtrip to validate their source address. So it maintains the advantage of one less roundtrip than TCP+TLS unless the server is receiving large amounts of connections that are not progressing in a timely manner.
• vasilvv 3y ago
  QUIC requires the initial handshake packets to be at least 1200 bytes, and sets the anti-amplification limit of 3x [0]. This means that the server can typically send up to 3600 bytes in response (unless the client's handshake message exceeds one packet, which usually only happens if there is a post-quantum key share in it). 3600 bytes is usually enough, unless your certificate chain is too large, in which case you'd need to compress it. [1] is a nice overview of the problem. (full disclosure: I worked on some of this stuff) [0] https://datatracker.ietf.org/doc/html/rfc9000#name-address-validation https://datatracker.ietf.org/doc/html/rfc9000#name-address-v... [1] https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study https://www.fastly.com/blog/quic-handshake-tls-compression-c...