Re: QUIC-LB update: Eliminate block ciphers?

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 06 October 2021 18:13 UTC

Return-Path: <hallam@gmail.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 4136D3A0063 for <quic@ietfa.amsl.com>; Wed, 6 Oct 2021 11:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 o_9Qkk3ZCyI1 for <quic@ietfa.amsl.com>; Wed, 6 Oct 2021 11:13:35 -0700 (PDT)
Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) (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 A6D213A0045 for <quic@ietf.org>; Wed, 6 Oct 2021 11:13:35 -0700 (PDT)
Received: by mail-yb1-f169.google.com with SMTP id g6so7498352ybb.3 for <quic@ietf.org>; Wed, 06 Oct 2021 11:13:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nqhFgkWsO0FuBdxgMCLsSmYd1yJFbPYEaZm701HUnck=; b=HsdFOzfmdFIcV2hJWq8aR5r/9efAnbCWVAD0Zm387X7IM/XwOXLaHmkQ6uA5XsNQX0 XuuvCHo+j4CGuHbBAvMZS0HFQqhV/NKEXbOKzlsQePOCfYbwbF89USxMnAuVfS2cV87t 70NJgBpLzLLMdMDTOqhFL1J2YuMD+gNHRVk2ccYo938VjRPBme0OII3TDE35LGvDFcvm 7VSQ+uEcKxzzHP9RFR5IzNc8Z2NE55sILUVkrTMobpe0IBH6BsULe+xFaIRg1PkZA/2a aI4XV1P7ptNodhDsEpqAtjGKdDBO1XRCGSecGE6L6gEEmQPPRZOoDJM4OG2hVj85jWXN tW9A==
X-Gm-Message-State: AOAM530doe4GkqrSYgQJTzMIyiuTOI4I0431sv//VGivk550oUSVr42p hKT76EmmBPCOG1676zt1AC8s15Gxl1Y2oItXono=
X-Google-Smtp-Source: ABdhPJy8KZZYKtEcBxGP19DMx503rn/xHCXUpqtmxX+DAOxHN6+pQyAi41Y6wNmRaJIUpbCXqGBk02g0xy6mUt3iHdk=
X-Received: by 2002:a25:5488:: with SMTP id i130mr31845056ybb.454.1633544014827; Wed, 06 Oct 2021 11:13:34 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CAM4esxQ7oUb2k3HKs21gUy15FxDr3wMDPH4EyR8FkX8q+a9A3Q@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 6 Oct 2021 14:13:23 -0400
Message-ID: <CAMm+Lwg2Ds=MdKXcry-ukRjc3nSjXy4XHXFdBU8eJP9S9xOchg@mail.gmail.com>
Subject: Re: QUIC-LB update: Eliminate block ciphers?
To: Martin Duke <martin.h.duke@gmail.com>
Cc: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Antoine FRESSANCOURT <antoine.fressancourt@huawei.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ba951705cdb31ad5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Wn3BZOULeSxFAvzKpX-RKtM12N4>
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 18:13:41 -0000

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