Re: Increasing QUIC connection ID size

Victor Vasiliev <> Fri, 12 January 2018 20:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A06761241F8 for <>; Fri, 12 Jan 2018 12:26:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Status: No, score=-2.01 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_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 w5UH_hE_B_y1 for <>; Fri, 12 Jan 2018 12:26:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 44E941200FC for <>; Fri, 12 Jan 2018 12:26:00 -0800 (PST)
Received: by with SMTP id u42so7524787qte.7 for <>; Fri, 12 Jan 2018 12:26:00 -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=KgBClCMxzOoFvMDyZ4Gg+9LkAufVnW2Ifecq5W5Q6Rs=; b=mMKdo0RJwtoczqseg5PM5im0+g46lOKcbUNn/ZM/Z6/VMRLkwwgYzrcBoYnTJoiP5z pQT+q2d3NcqX+U7PpfXyQ55w3VpedUN3cB8+oEHJAd9IFIRDsw37LVRLQjRbbTReHYeQ ikn8PgaK6/jt/zhVLqKnicEcxe5eL2KkCFP7jg3VLbEF9mVjlmdl2FXwoczJfBygWxz+ keG/i2rq17Os1zOa6JBDuMALE4gApjqGYTR46UU2IPgo48bQISyGQbqNhyVSoUkBxn5x T3WE67+aJemGxTccqTHRN3vwJuItB6k4pkhOG0FICLgWDgLr6whI8/9sOkFSOdbSSJjq yghw==
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=KgBClCMxzOoFvMDyZ4Gg+9LkAufVnW2Ifecq5W5Q6Rs=; b=OInvPOfzxp2+t6PqJYFYEh2VjMJEYifa6EkFU/9+qnKTelXPRlBTBJJvBtrXerShYu dTs6mYSVlZbnYXtUCrnP+ATt2AAY6MmFdkqV0bY2D8zf9QKaxilb7NDzZd4beQc3IECz VN08CaJYGjSpdw70MHBRl7wXGO7r61h3yiK4HWMeBFXntvxQIKMZZvwg3yRdxbuOjoaS p1fnoOUlGIps48uBKB254iieQnJR2ccnWKnT1SjXkjN2qGY9TqDDO/xh35/DHJ0zBavf me8+O4cBbtFVR0f68UnzMkJGDEBi4za6VIzCG/gxmia1SA3IW6kJ9TzabK30s/OI/9PI MVlQ==
X-Gm-Message-State: AKwxytdG6Z3ceAX7IqfyOhqQX7aEMz5BMGrP1b0ZE6Ag6HTGilIbbNbw 7Kgh+ULIzJ+LIT+cnXXudxD98LwtPSgpBktjq8FmUI1BmQU=
X-Google-Smtp-Source: ACJfBotUmx5tRB48kIJq8bXD0TUXhmb4upfime/1jZsIsJnqcfb3KKXMgpjU0Um78J+AfvVemvA81tP5W+4jwHO32wg=
X-Received: by with SMTP id i36mr3451213qte.116.1515788759142; Fri, 12 Jan 2018 12:25:59 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 12 Jan 2018 12:25:58 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Victor Vasiliev <>
Date: Fri, 12 Jan 2018 15:25:58 -0500
Message-ID: <>
Subject: Re: Increasing QUIC connection ID size
To: Christian Huitema <>
Content-Type: multipart/alternative; boundary="001a114774208bcadb05629a12d1"
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: Fri, 12 Jan 2018 20:26:03 -0000

On Thu, Jan 11, 2018 at 9:47 PM, Christian Huitema <>

> 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