Re: QUIC-LB update: Eliminate block ciphers?

Christian Huitema <huitema@huitema.net> Wed, 06 October 2021 23:44 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF9B3A0AD0 for <quic@ietfa.amsl.com>; Wed, 6 Oct 2021 16:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pleJc5N3lDOX for <quic@ietfa.amsl.com>; Wed, 6 Oct 2021 16:44:54 -0700 (PDT)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438D53A0AC1 for <quic@ietf.org>; Wed, 6 Oct 2021 16:44:54 -0700 (PDT)
Received: from xse209.mail2web.com ([66.113.196.209] helo=xse.mail2web.com) by mx136.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1mYGad-0001Dn-7S for quic@ietf.org; Thu, 07 Oct 2021 01:44:49 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4HPrf607YdzPGF for <quic@ietf.org>; Wed, 6 Oct 2021 16:44:46 -0700 (PDT)
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1mYGab-0008OP-S7 for quic@ietf.org; Wed, 06 Oct 2021 16:44:45 -0700
Received: (qmail 12546 invoked from network); 6 Oct 2021 23:44:45 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.46.217]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <mt@lowentropy.net>; 6 Oct 2021 23:44:45 -0000
To: Martin Duke <martin.h.duke@gmail.com>, Phillip Hallam-Baker <phill@hallambaker.com>
Cc: IETF QUIC WG <quic@ietf.org>, Martin Thomson <mt@lowentropy.net>
References: <CAM4esxT=QrJBaPsmK-6dXV+WUYn+tiHUEk_PpJu9L_agdU4EtQ@mail.gmail.com> <6f4f125359b247f588c8a74eb7ebfa1a@huawei.com> <CAKcm_gNRmKEDninEbHd6L_Jf7qJRBOvh5q2VyQT4FFabnDKL6g@mail.gmail.com> <CAM4esxQ7oUb2k3HKs21gUy15FxDr3wMDPH4EyR8FkX8q+a9A3Q@mail.gmail.com> <CAMm+Lwg2Ds=MdKXcry-ukRjc3nSjXy4XHXFdBU8eJP9S9xOchg@mail.gmail.com> <4c53f268-3d1b-562c-da5b-9973737464dc@huitema.net> <3ca56d7b-072e-4206-be10-c7732d796d36@www.fastmail.com> <CAMm+LwjazawphkGCAEeWKonfJrWdmc2mNBUPgeCrytzA1GA0Cg@mail.gmail.com> <CAM4esxTEHgzbS-6cOW7bh-9WN5LUsBLZqK9Sf1U1kdoMvz9eig@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Subject: Re: QUIC-LB update: Eliminate block ciphers?
Message-ID: <ec18922c-db43-d091-a692-17a18c3d5003@huitema.net>
Date: Wed, 6 Oct 2021 16:44:45 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <CAM4esxTEHgzbS-6cOW7bh-9WN5LUsBLZqK9Sf1U1kdoMvz9eig@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.196.209
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x6h2yQpzTslcOqazQkKtAFKj/EwzSHE5FGYwwjsNRPCIKo jxZxpPBdPM4eEbjU1njmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7ImcaqlHdH9stIYSUOP2ajLGtTxQ6V51u76v35b1wNe/MvdLom48E g3of4Y9DlgiJ0nAJ2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NQ/T3Op6Um662jkOH4Bxha/TyQVeo42Kibna4h1YueRnP t7CLTRHhPYwsW3prjsc/DRojSVizNl0ce/s7u0P9b9Tml6eOMCV9kYYwkPx6ZsXvIUzTXkDAiiJi mGhLUFuS2lhaIetXfCg1JdAVrOwKfInEYL4LLNIgfbl/R1uOJEpUoFIvD3sIcP1fhJPM6B/8j5tA xboVzkcAS/CPBADxtJb1dLGmuWjUDhUrPRIoxbiJ+dym1L8cD17Js0v4cp1MEX3FGXwLfNrGHfD+ GgCiATcKVNeVJ9BXyu9+ceCqThTYg2px1fSoqxQCCHnLMo/m9VKh99btUAanjnMCAH2co+fBoeG+ Hs0afhsY/5zhNYWRVYKU9W9tbmVXJBqdHHDmZEKhyNAv1N35kYWaEdgLurFV5oTvAcwA4rM3FkfW 8/1kE/e7sUnsVpINvARNxpFO
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/OfXlehK_LgkqtcClEXOo9Q60o_w>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Oct 2021 23:45:00 -0000

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 <phill@hallambaker.com>
> 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 <mt@lowentropy.net> 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.
>>>
>>>