I'm looking forward to https://datatracker.ietf.org/doc/html/draft-ietf-tls-cert-abridge-01
Certificate compression is probably enough to cut the costs down by 20% or so. The numbers for that draft [1] suggest that we can get to around 50% the size of an already-compressed certificate chain. I'm not in favour of lifting the amplification limit until we have exhausted those options. PQ certificates might change that, but that comes later. In the meantime, PQ key exchange is more urgent and that will *increase* the space we have available for certificates. [1] Estimated: https://github.com/tlswg/draft-ietf-tls-cert-abridge/tree/main/benchmarks On Thu, Aug 1, 2024, at 02:41, Nick Banks wrote: > Unfortunately, we don’t support certificate compression yet. I’d also > be interested in seeing the data with that enabled. I need to go see > if/how I can use that with OpenSSL. > > - Nick > > Sent from Outlook <http://aka.ms/weboutlook> > *From:* Ian Swett <ianswett=40google....@dmarc.ietf.org> > *Sent:* Wednesday, July 31, 2024 12:07 PM > *To:* Christian Huitema <huit...@huitema.net> > *Cc:* Paul Vixie <p...@redbarn.org>; IETF QUIC WG <quic@ietf.org>; Nick > Banks <niba...@microsoft.com> > *Subject:* Re: Proposal: Increase QUIC Amplification Limit to 5x > > 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
