Re: QUIC-LB update: Eliminate block ciphers?
Christian Huitema <huitema@huitema.net> Wed, 06 October 2021 20:02 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 26E503A0869 for <quic@ietfa.amsl.com>; Wed, 6 Oct 2021 13:02:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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 DYlCSqIp3f7H for <quic@ietfa.amsl.com>; Wed, 6 Oct 2021 13:02:25 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 028943A0866 for <quic@ietf.org>; Wed, 6 Oct 2021 13:02:24 -0700 (PDT)
Received: from xse429.mail2web.com ([66.113.197.175] helo=xse.mail2web.com) by mx134.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1mYD7K-0006Zt-IP for quic@ietf.org; Wed, 06 Oct 2021 22:02:21 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4HPljM1QYQz12tv for <quic@ietf.org>; Wed, 6 Oct 2021 13:02:15 -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 1mYD7H-0005z0-2G for quic@ietf.org; Wed, 06 Oct 2021 13:02:15 -0700
Received: (qmail 6847 invoked from network); 6 Oct 2021 20:02:14 -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 <ianswett=40google.com@dmarc.ietf.org>; 6 Oct 2021 20:02:14 -0000
Subject: Re: QUIC-LB update: Eliminate block ciphers?
To: Phillip Hallam-Baker <phill@hallambaker.com>, Martin Duke <martin.h.duke@gmail.com>
Cc: Antoine FRESSANCOURT <antoine.fressancourt@huawei.com>, IETF QUIC WG <quic@ietf.org>, Ian Swett <ianswett=40google.com@dmarc.ietf.org>
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>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <4c53f268-3d1b-562c-da5b-9973737464dc@huitema.net>
Date: Wed, 06 Oct 2021 13:02:14 -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: <CAMm+Lwg2Ds=MdKXcry-ukRjc3nSjXy4XHXFdBU8eJP9S9xOchg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: 66.113.197.175
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.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/EwzSHE5FGYwwjsNRPCKxp KtDOyJS1GIiHx+wejLPmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7ImcaqlHdH9stIYSUOP2ajLGtTxQ6V51u76v35b1wNe/MvdIN+Yj9 JT+HIE3AciYbXmyy2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NDxdyIeJZUl7T+dBx2dACj/TyQVeo42Kibna4h1YueRmQ /+Haa7ayiN6GUVqRBz5CDRojSVizNl0ce/s7u0P9b7Oijoc3SCZfWp1RjkjWCw/vIUzTXkDAiiJi mGhLUFuS2lhaIetXfCg1JdAVrOwKfIXBo9apH9ZUiVEOy5yxnE1UoFIvD3sIcP1fhJPM6B/8OwwH aDWTYUXZCzfcc15zjZyuUvaV4bwXiAmP35nCbbuJ+dym1L8cD17Js0v4cp1Mej7KAZ+GHQ+5pVd3 lNK/wjcKVNeVJ9BXyu9+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/TABDR_duSYRaZF1riAzHmm5KVzA>
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 20:02:31 -0000
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 Huitema On 10/6/2021 11:13 AM, Phillip Hallam-Baker wrote: > I came up against the same issue in a different spec. Stream ciphers appear > to be the solution but open up a large attack surface. Stream ciphers are > really difficult to get right and formal methods don't always help. There > is a tendency to reduce the problem to what can be proved. If you use a > stream cipher, you have to rekey for each encryption operation. > > Block ciphers are more expensive but they are really hard to mess up. > > One option is to use a shorter block cipher. I put out a request for > shorter block cipher on the Cryptography list and we had a discussion there > if people are interested in that approach. > > Yet another approach is to just use DES which has a short block. Which is > obviously insecure for data encryption but this application has weaker > requirements. > > > > > On Wed, Oct 6, 2021 at 12:33 PM Martin Duke <martin.h.duke@gmail.com> wrote: > >> Hi Antoine, >> >> Yes, the configuration agent generates the key in both cases. Sorry this >> is confusing; if the block cipher goes away, the entire section will need a >> deep editorial rewrite that will hopefully remove the confusion. >> >> Martin >> >> On Wed, Oct 6, 2021 at 2:58 AM Ian Swett <ianswett= >> 40google.com@dmarc.ietf.org> wrote: >> >>> I agree that the Block Cipher is not that likely to be deployed, and >>> removing it simplifies the draft. >>> >>> On Wed, Oct 6, 2021 at 5:26 AM Antoine FRESSANCOURT < >>> antoine.fressancourt@huawei.com> wrote: >>> >>>> Hello, >>>> >>>> >>>> >>>> A side remark on the Stream cipher and block cipher CID sections. As I >>>> was reading both sections, I struggled a bit with understanding which keys >>>> were used in each cryptographic operation. The block cipher section tells >>>> that the key is generated by the configuration agent and distributed to the >>>> LB, but there is no such mention for the stream cipher section. >>>> >>>> >>>> >>>> As I don’t have a clear view about how keys are created and managed, I >>>> would love to see those concerns answered in the draft (and unfortunately I >>>> would only be able to push misinformation myself) >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> >>>> Antoine Fressancourt >>>> >>>> >>>> >>>> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Martin Duke >>>> *Sent:* Monday, October 4, 2021 10:21 PM >>>> *To:* IETF QUIC WG <quic@ietf.org> >>>> *Subject:* QUIC-LB update: Eliminate block ciphers? >>>> >>>> >>>> >>>> Hello QUICWG, >>>> >>>> >>>> >>>> There has quietly been some recent work on tightening up the QUIC-LB >>>> specification. At the moment, we are still short on implementations but I >>>> am hearing something might happen soon. >>>> >>>> >>>> >>>> Anyway, Christian Huitema has made substantial contributions to the >>>> security properties of Stream Cipher CID, which allows smallish CIDs, by >>>> making it a three-pass algorithm. We still have the "Block Cipher CID >>>> option" which requires CIDs of at least 17 bytes; AFAICT the only advantage >>>> at this point is that it can be decoded with 1 block encryption operation >>>> instead of three. >>>> >>>> >>>> >>>> In principle, QUIC-LB load balancers can be run with no per-connection >>>> state, in which case this would be a per-packet operation. I strongly >>>> suspect that real LBs will keep some per-4tuple state, as they do today; if >>>> so, this crypto operation only needs to occur once per packet where the >>>> 4-tuple is new. If so, the CPU impact is vanishingly small except in a >>>> storm of garbage packets. >>>> >>>> >>>> >>>> So AFAICT, the use case for Block Cipher is as follows: >>>> >>>> - Willing to run one crypto operation per packet/new 4-tuple >>>> >>>> - Not OK with doing three crypto operations >>>> >>>> - satisfied with 17B + CIDs >>>> >>>> >>>> >>>> I strongly suspect this does not describe a real implementer, and am >>>> inclined to simply delete this option in my effort to simplify the design. >>>> Nevertheless, I'm taking this to the list in case someone thinks this is an >>>> important use case. >>>> >>>> >>>> >>>> This is Issue 138 in Github >>>> <https://github.com/quicwg/load-balancers/issues/138>. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Martin >>>> >>>> >>>>
- QUIC-LB update: Eliminate block ciphers? Martin Duke
- RE: QUIC-LB update: Eliminate block ciphers? Antoine FRESSANCOURT
- Re: QUIC-LB update: Eliminate block ciphers? Ian Swett
- Re: QUIC-LB update: Eliminate block ciphers? Martin Duke
- Re: QUIC-LB update: Eliminate block ciphers? Phillip Hallam-Baker
- Re: QUIC-LB update: Eliminate block ciphers? Christian Huitema
- Re: QUIC-LB update: Eliminate block ciphers? Phillip Hallam-Baker
- Re: QUIC-LB update: Eliminate block ciphers? Martin Thomson
- Re: QUIC-LB update: Eliminate block ciphers? Phillip Hallam-Baker
- Re: QUIC-LB update: Eliminate block ciphers? Martin Duke
- Re: QUIC-LB update: Eliminate block ciphers? Christian Huitema