Re: Increasing QUIC connection ID size

Jana Iyengar <> Sat, 13 January 2018 01:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0BA4126B6E for <>; Fri, 12 Jan 2018 17:06:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r_kAe1CHlhe4 for <>; Fri, 12 Jan 2018 17:06:50 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 593D81250B8 for <>; Fri, 12 Jan 2018 17:06:50 -0800 (PST)
Received: by with SMTP id m19so3248174ywh.12 for <>; Fri, 12 Jan 2018 17:06:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jf1wF2kuR+QWY9wu+uyrLCUHHXSf6DqiedT2cac3E/8=; b=PJeFwDtJtx1iyYBZ3J+ds/wN3bJj1I/dlaPyiWMsRsOy6z/hOHZYTdLUnOlbS8IZDp 3PqlsYtJQnYv2kxn6GFHXg8ndJw9BHabYDyufcnc0MINDpUQHMCBy/CGseVA4xbGZQSR VumEYzz64YMnS971z4hxTyxQzMB5verqh7/is3F9+E4W7RVAEMkQU6mY9tKWWxgx/3SR +Vfc+8DfENhrDg6G5LYX626U2qObZFFeHOJPPM2Avj6nS5LkcTT4LMVX3EapLs7vAWYT vKIrcoKw3y5s39HrP6bcEgK21nTCSz4gFduCP+sGbywhQgAhCYG4ejl3S3B9i4GPxhKp HKNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jf1wF2kuR+QWY9wu+uyrLCUHHXSf6DqiedT2cac3E/8=; b=DgTakB0oCjqR/blzd9PyJ7Yy+4453fpURNOj6FY7eY4fl5rAUZWDA11ACAutHot8+h J66GG5UbC+K9/B9sP2E8e4emQqzTRr6W53n2yFHc1K7jRNIxOA3mVvuTiZSJE+mXQAOb MlDVYHfyXO1uB7aCxMI6Y8WOv4SDVmuoyrw3eSo2RbnazSqvBMIEIzndNHWltimgpvQF vMHzzjD3BnXuhMmrjMdcNdlOCe5afPTMQ2sQYhrlSktfHiv4s0Lm4LhNeABRjAnP0hct 9Adxiiq61P9WRZCjm+8yxVeIxlSHuSaH3o4sNAwym3O4Fcwz8HIPioBr4Lh1H3VFkat0 kbXw==
X-Gm-Message-State: AKwxytdRXfE3lwI3fTIx+dPSRIRRiz0b2c1aWpW7PhDAN/mbD+wUkQCO j5UpbeKEhRaDsmYOOssRk9O92kvj+G6DIueLIfxwEntW
X-Google-Smtp-Source: ACJfBotSG2OLP7KCB25OY94m71U33roM2OqgwHlkbJx646t2NVbvyRPoD5PJHve8afg63d6bRIMAeK0uglAflElbrE0=
X-Received: by with SMTP id l124mr9940642ywb.139.1515805609166; Fri, 12 Jan 2018 17:06:49 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 12 Jan 2018 17:06:48 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: Jana Iyengar <>
Date: Fri, 12 Jan 2018 17:06:48 -0800
Message-ID: <>
Subject: Re: Increasing QUIC connection ID size
To: Victor Vasiliev <>
Cc: Christian Huitema <>, IETF QUIC WG <>
Content-Type: multipart/alternative; boundary="001a113aa1ece2c18605629dfedd"
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 01:06:53 -0000

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.
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

On Fri, Jan 12, 2018 at 12:25 PM, Victor Vasiliev <>

> On Thu, Jan 11, 2018 at 9:47 PM, Christian Huitema <>
> wrote:
>> We have a prototype implementation in Picoquic in which the connection ID
>> can be split so some bits are random and some bits are used for routing to
>> a specific server -- thanks Igor for that. It makes for nice experiments,
>> but it is a denial of service waiting to happen. For example, attackers
>> could set the bits in such a way as to target a specific server in a pool,
>> or they could learn which connections are on the same server and use that
>> later for some kind of same server attack. It would be better if that
>> information was not in clear text. In fact, the picoquic implementation use
>> a callback to ask for the new value -- presumably from the router. That
>> callback could return anything, including an encrypted value.
> Indeed.  Besides DOS concerns, there's also desire to preserve privacy
> across connection migration.
>> On the other hand, it is not clear to me that we need full encryption.
>> For example, assume that the server that needs a connection ID can ask it
>> from the router. The router could pick one at random, make sure that it is
>> properly documented in the routing tables and that there is no collision,
>> and then pass it back to the server. No encryption needed, but of course
>> lots of state.
> This is in fact fairly painful from operational standpoint.
>> If the router does not want to keep the state, it can indeed create a
>> connection ID by encrypting a <nonce, server-ID> tuple. But it does not
>> follow that the encryption needs to be 128 bits. For example, it could use
>> a 64 bit algorithm like Blowfish.
>> So I am not sure that we actually need to change the length. And I am a
>> bit concerned by the incremental overhead if the connection ID suddenly
>> becomes very large.
> Well, the general idea I was considering goes like this: assume F(x) is a
> block cipher, and H(x) is a hash function the load balances uses to route
> packets.  Then the LB computes F(CID), and checks if it's formatted as
> <server-ID, client nonce, N zeroes>.  If it is well-formed, route based on
> server-ID or H(server-ID), otherwise route based on H(CID).  This way, the
> server-specified CIDs are tamper-proof in a sense that based on the usual
> assumptions about block ciphers, you can't do better than rolling a random
> CID and bypassing the check with probability 2^-N.  This of course,
> requires large N, and if you're running a lot of servers, have a lot of
> clients, it's very hard to fit everything into 64 bits.
> Another idea is that you just always compute <server entropy, client
> entropy> = F(CID), and just do H(server entropy).  This is also secure and
> allows the server to create unlinkable "come back to me" connection IDs
> while only sharing the key between the LB and the server, but assumes you
> don't want to be clever with your server IDs and just hash on them.
> Both of them suffer from the problem that F(x) has to be 64-bit, which
> leads into an uncomfortably exciting territory of non-standard crypto
> constructions (since all block ciphers made and standardized by IETF in
> this century have 128-bit blocks as far as I know), where you end up
> either using older stuff like Blowfish or using FPE techniques -- both of
> which are going to be slower than hardware AES.
> I do very much agree with the overhead concern, though, this is a tough
> question.