Feedback-ID: ic129442d:Fastmail
MIME-Version: 1.0
Date: Thu, 01 Aug 2024 11:30:53 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: "Nick Banks" <nibanks=40microsoft.com@dmarc.ietf.org>,
 "Ian Swett" <ianswett=40google.com@dmarc.ietf.org>,
 "Christian Huitema" <huitema@huitema.net>
Message-Id: <1375bdba-8671-4b4d-af86-8f7e6132db6c@betaapp.fastmail.com>
In-Reply-To: 
 <DM4PR21MB3130A7C56A8D0D5C41FA9F59B3B12@DM4PR21MB3130.namprd21.prod.outlook.com>
References: 
 <BL1PR21MB31152570F4497EBE91B3AF9FB3B02@BL1PR21MB3115.namprd21.prod.outlook.com>
 <4aac2fae-ddc6-453c-b974-751a7a37967c@redbarn.org>
 <ac725575-da13-4365-90ce-8ea55bc46e72@huitema.net>
 <CAKcm_gOCJha0ey38+L3MUEmCxdid4NoJQUVXzp=qaVM0Sh-QCg@mail.gmail.com>
 <DM4PR21MB3130A7C56A8D0D5C41FA9F59B3B12@DM4PR21MB3130.namprd21.prod.outlook.com>
Subject: Re: Proposal: Increase QUIC Amplification Limit to 5x
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: LGMEFK6EYEVZXLTC4CGLJEUBEFGYSF6V
CC: Paul Vixie <paul@redbarn.org>, IETF QUIC WG <quic@ietf.org>
Precedence: list
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/quic/oOR0V89bJYhed-pR3aVNzxwR8Ks>

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 exhau=
sted those options.  PQ certificates might change that, but that comes l=
ater.  In the meantime, PQ key exchange is more urgent and that will *in=
crease* 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=E2=80=99t support certificate compression yet. I=
=E2=80=99d also=20
> be interested in seeing the data with that enabled. I need to go see=20
> if/how I can use that with OpenSSL.
>=20
> - Nick
>=20
> Sent from Outlook <http://aka.ms/weboutlook>
> *From:* Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>=20
> *Sent:* Wednesday, July 31, 2024 12:07 PM
> *To:* Christian Huitema <huitema@huitema.net>
> *Cc:* Paul Vixie <paul@redbarn.org>; IETF QUIC WG <quic@ietf.org>; Nic=
k=20
> Banks <nibanks@microsoft.com>
> *Subject:* Re: Proposal: Increase QUIC Amplification Limit to 5x
>=20
> We found that once we deployed certificate compression, we could=20
> typically keep the cert under 3 packets, but without it, we typically=20
> went over.  I believe one reason the QUIC WG chose 3 is because we had=20
> data to show that most certificates were small enough once compressed=20
> to enable a 1 RTT handshake.
>=20
> I'd be curious what your results are with and without certificate=20
> compression in your client?
>=20
> On Wed, Jul 31, 2024 at 11:15=E2=80=AFAM Christian Huitema <huitema@hu=
itema.net> wrote:
>>=20
>>=20
>> 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=20
>> > limit the same way it moved beyond the old one? If it's some bizarr=
e=20
>> > kind of leaky bucket let's have the showdown now rather than later =
when=20
>> > everything is larger and ossification has begun.
>>=20
>> The concern is that the wily hackers will send a single UDP "initial"=20
>> packet to a server, and the the server will reply with a complete fli=
ght=20
>> of packets including key exchanges, parameters and certificates. Send=20
>> 1.2KB to the server, see the server send back 5, 6 or maybe 10 packet=
s=20
>> to the source IP of the UDP packet. With that the DDOS attack has bee=
n=20
>> "amplified" 5, 6 or maybe 10 times.
>>=20
>> The amplification limit is there to limit the usefulness of QUIC serv=
ers=20
>> for these DDOS attackers. The value 3 was chosen because with=20
>> "reasonable" configurations the server's first flight fits in 2 or 3=20
>> packets, and that there are many UDP services that provide more than =
3x=20
>> amplification (see=20
>> https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplific=
ation-attacks).
>>=20
>> But if we loosen the QUIC amplification limit while other services ar=
e=20
>> tightening, that situation will change.
>>=20
>> -- Christian Huitema