RE: QUIC-LB update: Eliminate block ciphers?

Antoine FRESSANCOURT <antoine.fressancourt@huawei.com> Wed, 06 October 2021 09:25 UTC

Return-Path: <antoine.fressancourt@huawei.com>
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 B75D63A18F7 for <quic@ietfa.amsl.com>; Wed, 6 Oct 2021 02:25:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 spbyDV__vfU6 for <quic@ietfa.amsl.com>; Wed, 6 Oct 2021 02:25:51 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B9E3A18FD for <quic@ietf.org>; Wed, 6 Oct 2021 02:25:51 -0700 (PDT)
Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HPTWq0xH6z67Zjl for <quic@ietf.org>; Wed, 6 Oct 2021 17:23:03 +0800 (CST)
Received: from lhreml727-chm.china.huawei.com (10.201.108.78) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Wed, 6 Oct 2021 11:25:47 +0200
Received: from lhreml726-chm.china.huawei.com (10.201.108.77) by lhreml727-chm.china.huawei.com (10.201.108.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Wed, 6 Oct 2021 10:25:47 +0100
Received: from lhreml726-chm.china.huawei.com ([10.201.108.77]) by lhreml726-chm.china.huawei.com ([10.201.108.77]) with mapi id 15.01.2308.008; Wed, 6 Oct 2021 10:25:47 +0100
From: Antoine FRESSANCOURT <antoine.fressancourt@huawei.com>
To: IETF QUIC WG <quic@ietf.org>
Subject: RE: QUIC-LB update: Eliminate block ciphers?
Thread-Topic: QUIC-LB update: Eliminate block ciphers?
Thread-Index: AQHXuV2BuxgQAOEMn0GANgfQnOCzbqvFtClA
Date: Wed, 6 Oct 2021 09:25:47 +0000
Message-ID: <6f4f125359b247f588c8a74eb7ebfa1a@huawei.com>
References: <CAM4esxT=QrJBaPsmK-6dXV+WUYn+tiHUEk_PpJu9L_agdU4EtQ@mail.gmail.com>
In-Reply-To: <CAM4esxT=QrJBaPsmK-6dXV+WUYn+tiHUEk_PpJu9L_agdU4EtQ@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.53.81]
Content-Type: multipart/alternative; boundary="_000_6f4f125359b247f588c8a74eb7ebfa1ahuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/veclXhGck5jSjv4BlaxDjUSfHA8>
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 09:25:56 -0000

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

Thanks,
Martin