Re: [TLS] Before we PQC... Re: PQC key exchange sizes

Phillip Hallam-Baker <ietf@hallambaker.com> Sun, 07 August 2022 17:03 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31980C15BEC6 for <tls@ietfa.amsl.com>; Sun, 7 Aug 2022 10:03:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.431
X-Spam-Level:
X-Spam-Status: No, score=-6.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yK5GeKyA3ru for <tls@ietfa.amsl.com>; Sun, 7 Aug 2022 10:03:14 -0700 (PDT)
Received: from mail-oa1-f54.google.com (mail-oa1-f54.google.com [209.85.160.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CF40C15B24B for <tls@ietf.org>; Sun, 7 Aug 2022 10:03:14 -0700 (PDT)
Received: by mail-oa1-f54.google.com with SMTP id 586e51a60fabf-10ea9ef5838so8168396fac.3 for <tls@ietf.org>; Sun, 07 Aug 2022 10:03:14 -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=pb8aXUcjAuJo5KyCD/2M6eAsL8x3ekutWEhzyXpeoyk=; b=VTIGxf3MMe18dUJIsTnu8DPKYqg4QUtMiKECxAJIGfI9FNPXUezUN7zB37bQ3xgh9o Mp1D5MMhZVmW3ZVMVDe8YThi3cbaCLgUO5zN/htt170O+Lmd9ivc/73o6SGo09Fw/aua zWW9WkqX1P9SugfJWxLTnmokilTAsA0WWDP/RJPA9z3pgOgz3MOAb7Bu5uZG/yMgjSEY BpWgzsPaLyBEQvSDPWhm+4/lxRm6JbjERqu4fwuCmyDw34PO7bzuRuQSinextLy9A1G/ 83IyUTjWsAfnTGrMYYGKDzm+PDYReB5x8Cyqrwt0SJhbh+79S68cJqZ4bWEwotIn7y8J cTcQ==
X-Gm-Message-State: ACgBeo3HnYtj9rs3oOhZDb+1eHv3Ur1D+D9zfeGATJKJ6rmH3Z72eqyT xzDV3zYzpwVacCzLMEGCvACOCnSsyDuReAR+6c3SMG+bqoI12w==
X-Google-Smtp-Source: AA6agR6ENyER6u5DOmXK8lsIrqduFAjCwN7RzDIpUzP0Dy2cu2jpG/nd8voQnYoEdA3oCA/GiWNQQUs5BUNLVggQfrA=
X-Received: by 2002:a05:6870:9590:b0:de:27ca:c60c with SMTP id k16-20020a056870959000b000de27cac60cmr10729960oao.108.1659891793798; Sun, 07 Aug 2022 10:03:13 -0700 (PDT)
MIME-Version: 1.0
References: <CABzBS7nsbEhR-bmHG_ViSJFSH-0_5p0O3vKndS4+wFR=iGQzhw@mail.gmail.com> <CAMm+LwgAzb4t=awzpU4Sb5j7Bf6DuR3u+23n+h_C3Pnsin-SHg@mail.gmail.com> <8383756C-5595-4028-9E5E-8B758147ED33@ll.mit.edu> <CAMm+LwgHNL_aHqK+TbdBf=xJBPftjkXL_=isXUJB+mbiUc7_Lw@mail.gmail.com> <58778bee-ccd8-3b6b-cdf3-7392cd6f3187@riseup.net> <CAChr6SxXVzKptFzDEczOUzVf+LGSNxY=rk45DgXceg_anA_SPQ@mail.gmail.com> <20220806051541.GQ3579@akamai.com> <CAChr6Sy3vGbcDCDXWOGNwLQgwZZG_z3HTSgz54Ch2_vurF++RA@mail.gmail.com> <CAMm+Lwj19zmbPo+53Zk8m3AOWPGF8mhyB9SPTVP7mP0DsWpPzQ@mail.gmail.com> <SY4PR01MB62514622B4DE2AF47F1B1DD2EE609@SY4PR01MB6251.ausprd01.prod.outlook.com>
In-Reply-To: <SY4PR01MB62514622B4DE2AF47F1B1DD2EE609@SY4PR01MB6251.ausprd01.prod.outlook.com>
From: Phillip Hallam-Baker <ietf@hallambaker.com>
Date: Sun, 07 Aug 2022 13:03:02 -0400
Message-ID: <CAMm+LwhdxdWJsqCW295Byu1OFDqbTnJR91MFdBHAY6tkk59Jag@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bc2c8805e5a9ac6e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WqNn2WxSaydMFIx4pD8v8_YR3EA>
Subject: Re: [TLS] Before we PQC... Re: PQC key exchange sizes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Aug 2022 17:03:19 -0000

On Sun, Aug 7, 2022 at 3:52 AM Peter Gutmann <pgut001@cs.auckland.ac.nz>
wrote:

> Phillip Hallam-Baker <ietf@hallambaker.com> writes:
>
> >Quantum Annoyance:
>
> I thought a Quantum Annoyance was someone who keeps banging on about
> imaginary
> attacks that don't exist as a means of avoiding having to deal with actual
> attacks that have been happening for years without being addressed.
>

That is a little unfair but only a little.

What bothers me is that TLS is not a toy, it is the primary security
control used in most of the world's critical infrastructure. That is why
Quantum Cryptanalysis has to be take seriously.

But so does the fact that Rainbow fell to an attack discovered during the
competition. This is not mature crypto, it is not ready for prime time as a
sole control. I have seen references to a 'NIST' slide insisting that we
should not use hybrid schemes and I completely disagree with them. KGB
doctrine was always that every communication be secured by two independent
technologies using separate principles..

I suspect that this guidance is being misinterpreted and that what they
actually meant was that the PQC algorithms have to be fit for purpose as a
sole control.

First, do no harm: At this point it is very clear that the risk of a Laptop
on a Weekend breaking Kyber is rather higher than anyone building a QCC
capable computer in the next decade. So what is not going to happen is a
system in which a break of Kyber results in a break of TLS.


Critical infrastructure demands defense in depth. The lack of binding
between the ephemeral and the initial exchanges was always a design blunder
in TLS. Using an ephemeral should never weaken the security.

Incidentally, this particular design blunder is one of the reasons I am
sceptical of security proofs using formal methods. The problem with formal
methods is that you can only prove correctness with respect to a
specification and if the specification is wrong, all else fails. Unless you
start asking questions like 'what if this assumption fails', you end up
with systems with a single point of failure. And before folk start telling
me how great formal methods are, I was a practitioner once.