QUIC-LB update: Eliminate block ciphers?

Martin Duke <martin.h.duke@gmail.com> Mon, 04 October 2021 20:21 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0DE5E3A0BCF for <quic@ietfa.amsl.com>; Mon, 4 Oct 2021 13:21:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id TudMund2JkqW for <quic@ietfa.amsl.com>; Mon, 4 Oct 2021 13:20:58 -0700 (PDT)
Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 313683A0BC8 for <quic@ietf.org>; Mon, 4 Oct 2021 13:20:58 -0700 (PDT)
Received: by mail-ua1-x931.google.com with SMTP id b34so13316151uad.8 for <quic@ietf.org>; Mon, 04 Oct 2021 13:20:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=6I5RXcSrxBC+SsTDQiX1j9dht79MB1xE+hGYBMGd39c=; b=WVthSmlexCQoWNPrqRB1bbd3/hgUEJ/KgO1bYCF/RN9j9lEzGS6JauH73EOzst2xRD hx/hRQyv+DJuuCes+NZGY0q30k++tTpeHF1EsVqTRV5Wj5kRM/r8NQxCpzdcDVYIC89Y PJH6R43OXoR1Jz6a27t5beMiVHXMaUWfu/nbCMdxPAllhQbSAq1DM8sN+k1+IxHXKyGd PCk2D30IzL6y9sTiSmdOJHZFpyn8HNItEWxEQdsxI+qQJXmvgNEte1vuEPR+5cjYYBoN uPUpnW0BZ48NwL0acZPO/81Q4oYnRjSIjKYh0975cDBkdvSeddfEqrVtR5t31mI7c4yw FNYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6I5RXcSrxBC+SsTDQiX1j9dht79MB1xE+hGYBMGd39c=; b=EsfdCqF8Mi6kAQwr9WdGzcDMGG9b5s/V9HDcRyC39TNsg9Frj2XplWblf7rxiGL3gz K4mSDPPEoDnsOdwAjl7/wJGcuLRtSI1lvGy7hSUSg14VgUlWbc+kfVUjZnvLfB3F6Obn +MFokBVyxcGGItLzInCGBF6P4bae3g8D2zrYbKSAHN5uS7Th8l4S78KNmSiVVzsPXFWq 7ikLTb/tm458ROTP2e5cAIC55Rkb4+pw/exK9tsGDnTDowNyBvDOepKNNQHnobeSQvTk EiTBgmFfKui6R7DHHBMICO5htKPNB4211TRCwUf61KxKvkj0R3GaNYLGFJcDu0ISnq3L TkLg==
X-Gm-Message-State: AOAM531nMqRc53PkGfGZy3rC6CMyEn3Ws1tzPktUwXmSWd1MU/WssCVu iCLyRf5QhjagIwfQHUoX+yLDv0qzDgJDmPwB8ePkoikkBf8=
X-Google-Smtp-Source: ABdhPJxn/QGD8rtdMe3uh4Y5K+cVL1M8veJZcThnDOsVjWOthlqqOU5m6qAJ7uMdugFJJdr8GCghJra2IxVIcWq3khI=
X-Received: by 2002:ab0:5542:: with SMTP id u2mr8835228uaa.62.1633378856837; Mon, 04 Oct 2021 13:20:56 -0700 (PDT)
MIME-Version: 1.0
From: Martin Duke <martin.h.duke@gmail.com>
Date: Mon, 04 Oct 2021 13:20:45 -0700
Message-ID: <CAM4esxT=QrJBaPsmK-6dXV+WUYn+tiHUEk_PpJu9L_agdU4EtQ@mail.gmail.com>
Subject: QUIC-LB update: Eliminate block ciphers?
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008ba79605cd8ca6ae"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/0JJxG7LZinXvTFq9cxQb7IwbN24>
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: Mon, 04 Oct 2021 20:21:00 -0000


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