Re: Increasing QUIC connection ID size

[Victor Vasiliev <[e-mail]>]

On Thu, Jan 11, 2018 at 9:47 PM, Christian Huitema <[e-mail]>
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.