Re: Increasing QUIC connection ID size

Christian Huitema <> Sat, 13 January 2018 02:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E4B8124B17 for <>; Fri, 12 Jan 2018 18:12:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JHTgEZXaYqL4 for <>; Fri, 12 Jan 2018 18:12:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 78D98120726 for <>; Fri, 12 Jan 2018 18:12:41 -0800 (PST)
Received: from ([]) by with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <>) id 1eaBJG-0004mz-3i for; Sat, 13 Jan 2018 03:12:39 +0100
Received: from [] ( by with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <>) id 1eaBJE-00060f-F1 for; Fri, 12 Jan 2018 21:12:37 -0500
Received: (qmail 20757 invoked from network); 13 Jan 2018 02:12:34 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 13 Jan 2018 02:12:34 -0000
To: Jana Iyengar <>, Victor Vasiliev <>
References: <> <> <> <> <> <>
From: Christian Huitema <>
Message-ID: <>
Date: Fri, 12 Jan 2018 16:12:31 -1000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: Increasing QUIC connection ID size
Authentication-Results:; auth=pass smtp.auth=
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.25)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5tVpDtamcLd2Mq5LQSaa1fYXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fue1Em106DLigPU1Bg9Z1uDB98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXtfZdf1siwYNJirk4ABKayRZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Xq4ax6KvrI/nhOyr4XmBA0QaRU5G7TB9RBnrQ7zv+k CkRb4pNhyTIO3GRvAPdGzxbpouDQrFmDFpjkCkgYFE/ex6JvzKixj8PC+OqalCFkmpH+vpUDIZeJ XjrpEEsmd+8wbu9lcViFVxDhGp2PwufGcyNBJprCgmabT8JgPqpM5ie72Bnan8Jx5EdaC4dMALJy vaMJjrieG2srn00plTxbPC1Q5Dqh9+e+4N356TJlGVz1pRXWhjh9fdbl44I0Df0tN9eq0V0hlrWD EiOHLhiBv/meE53U+r4e00fXx1F/BR3h1vgDbEdmhrg3iVBpdRYOufOwbl/5xojV0vlh7+TwGpIO PepTCxFMvIavjx/iA3YOJbgNLT0Ix6mdJEErnNhWBb39uS1TjWG2Inx+Ts2QvrhVVD6SNHfaCiIW OOQAkvVDEoFOK6EAWKQ3WFIxRUtYANHDTJAVnZcGvok0a1Vj
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 13 Jan 2018 02:12:43 -0000

On 1/12/2018 3:06 PM, Jana Iyengar wrote:
> I'm not entirely convinced of the overhead concern. In the common HTTP
> case, we expect server->client to not carry CIDs, so this is a NOP in
> the commonly bandwidth-limited case.

Not just the transmission overhead. You are also increasing the memory
footprint of the connection context, which stores at least 2 CNX-ID, and
maybe more if we want to support migration.

But I agree that this is not the end of the world.

Also, following Victor's message, I was doing the maths on the size of
the ID. 64 bits allows for 24 bits of server ID, 32 bits of client
nonce, and 8 bits of zero -- for checking. 8 bits check will still let
0.4% of forged packets through, which is probably OK since the server
acts as a backstop. 24 bits would work for 16M servers, which should be
OK, but assumes that servers have a unique serial ID, which is not
necessarily OK. Then 32 bits look like they allow 4G connections per
server, but we start seeing collisions after 65K connections per server,
which seems not good. So, yes, 64 bits probably will be very tight if we
want the router to be stateless.

> I do think that this makes CID generation at servers substantially
> simpler -- you can simply add 1 to the current CID to generate a new
> one, and encryption makes it unlinkable to the previous one. This is a
> substantial benefit.

Yes, you can do that without relying on a secure random generator, and
thus without exposing more of the state of the crypto PRNG. Which is
nice. Another advantage, if the router can reliably map connection-ID to
servers, then we don't need to have the same reset secret for every server.

Just one request. If we do make a change, please go for a fixed size.

-- Christian Huitema