Re: QUIC-LB update: Eliminate block ciphers?

[Christian Huitema <[e-mail]>]

As for the 'desired properties' of the encrypted method, there are 
basically two:

1- Make it somewhat hard for outsiders to generate connection 
identifiers that the load balancer will find valid.

2- Make it really hard for outsiders to generate or select connection 
identifiers that target a specific server in the farm.

The first one is actually kind of squishy, because it amounts to using 
longer identifiers than necessary, which does not improve performance. 
But in any case, the encrypted design should allow deployments to pick 
their one trade-off there. I do believe that the proposed design meets 
that goal.

The second goal is the key difference between the encrypted and clear 
text methods. I do believe that the current design meets that goal, 
because every bit of output depend statistically on all bits of input. 
But I agree with Phil and Martin that we should get an expert review. In 
fact I did ask the security ADs to help us organize that, a couple days ago.

-- Christian Huitema

On 10/6/2021 4:27 PM, Martin Duke wrote:
> If the Block Cipher goes away, this will simply be the "encrypted" method.
> No need to bikeshed the name for now.
>
> On Wed, Oct 6, 2021 at 4:21 PM Phillip Hallam-Baker <[e-mail]>
> wrote:
>
>> I think this is a different cryptographic construct and we should create a
>> name for the generic. Something like Keyed Permutation.
>>
>> Rather than bikeshed the name here, I propose taking it to either CFRG or
>> the Cryptography list (or both) to socialize the concept. It is quite
>> possible that there is a prior nomenclature we should follow.
>>
>>
>> It is not clear to me what the precise security properties required here
>> are. For my particular application, they are fairly weak because I am only
>> providing some traffic analysis resistance. I am not interested in
>> plaintext recovery attack, but I do care about the attacker being able to
>> discover that E(n), E(N+1) are a sequence.
>>
>> None of my systems are going to collapse if this primitive is broken but
>> it might afford a foothold.
>>
>>
>> On Wed, Oct 6, 2021 at 6:13 PM Martin Thomson <[e-mail]> wrote:
>>
>>> On Thu, Oct 7, 2021, at 07:02, Christian Huitema wrote:
>>>> Phil,
>>>>
>>>> What we have in the current LB spec is called a "stream cipher", but
>>>> that's a misnomer. What we have in the spec is actually a variable size
>>>> block cipher, derived from AES-ECB using a construct similar to FFX.
>>>> Your review of that algorithm would be appreciated.
>>> Christian,
>>>
>>> I would call this a Feistel network, but avoid talking about FFX.  FFX
>>> has a bunch of guidance about the number of iterations of the network that
>>> this ignores; to call this FFX or even imply that it is FFX isn't really
>>> fair.  When you get right down to it, the real contribution in FFX is the
>>> analysis that produces guidance on the number of iterations and the
>>> inclusion of tweaks; if you use neither, then it's not really FFX.  As
>>> additional iterations are necessary to maintain a security level, we need
>>> to be careful about the claims we make in relation to security.
>>>
>>>