Re: Increasing QUIC connection ID size

[Jana Iyengar <[e-mail]>]

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



On Fri, Jan 12, 2018 at 12:25 PM, Victor Vasiliev <[e-mail]>
wrote:

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