We found that once we deployed certificate compression, we could typically keep the cert under 3 packets, but without it, we typically went over. I believe one reason the QUIC WG chose 3 is because we had data to show that most certificates were small enough once compressed to enable a 1 RTT handshake.
I'd be curious what your results are with and without certificate compression in your client? On Wed, Jul 31, 2024 at 11:15 AM Christian Huitema <huit...@huitema.net> wrote: > > > On 7/30/2024 5:52 PM, Paul Vixie wrote: > > Do we know a reason why the system's behavior won't move beyond the new > > limit the same way it moved beyond the old one? If it's some bizarre > > kind of leaky bucket let's have the showdown now rather than later when > > everything is larger and ossification has begun. > > The concern is that the wily hackers will send a single UDP "initial" > packet to a server, and the the server will reply with a complete flight > of packets including key exchanges, parameters and certificates. Send > 1.2KB to the server, see the server send back 5, 6 or maybe 10 packets > to the source IP of the UDP packet. With that the DDOS attack has been > "amplified" 5, 6 or maybe 10 times. > > The amplification limit is there to limit the usefulness of QUIC servers > for these DDOS attackers. The value 3 was chosen because with > "reasonable" configurations the server's first flight fits in 2 or 3 > packets, and that there are many UDP services that provide more than 3x > amplification (see > > https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-attacks > ). > > But if we loosen the QUIC amplification limit while other services are > tightening, that situation will change. > > -- Christian Huitema > >
