IETF Logo Mail Archive

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

Robert Relyea <rrelyea@redhat.com> Tue, 09 August 2022 20:57 UTC

Return-Path: <rrelyea@redhat.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 9AE59C157B50 for <tls@ietfa.amsl.com>; Tue, 9 Aug 2022 13:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.687
X-Spam-Level:
X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.582, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
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 c0RLsxJpnUBU for <tls@ietfa.amsl.com>; Tue, 9 Aug 2022 13:57:31 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 3ED68C14CF01 for <tls@ietf.org>; Tue, 9 Aug 2022 13:57:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660078649; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6Y29MGoTWFoKj4vgz6n6ndf93nSkLjUNVVaL4EIAH1Y=; b=CtCuRYulquMDpw5j+QYvic4g/pcXuS3i8942ERxK2XVWcsZUdV0sgFt7J6vwJovDoKRQhz jRdkaJiXXP346/W6cdJGB8hY7wUJgAD/wjd66GuSzvQ9VlYet7KzA0fOdY7kPzZ3l7VBDN 2hXsXr5sEEIwuYfCVZDq+i4g37E1VUg=
Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-473-7MBoQUV-OWaZjh8ASCQpgg-1; Tue, 09 Aug 2022 16:57:28 -0400
X-MC-Unique: 7MBoQUV-OWaZjh8ASCQpgg-1
Received: by mail-qk1-f200.google.com with SMTP id s9-20020a05620a254900b006b54dd4d6deso11045367qko.3 for <tls@ietf.org>; Tue, 09 Aug 2022 13:57:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc; bh=6Y29MGoTWFoKj4vgz6n6ndf93nSkLjUNVVaL4EIAH1Y=; b=PLuV4Zs/6yw9FPQIsDxhpxZF5xTPX11gEReGSFCweU/pYBykdXC64Leuw5D5pTd5rd ++6DQzuuPvBGSbt/AbVLY98XpMo+ZkYWEIXBjbwVdgsBwNsdfHSZ5dgkHO3RaWJ8oT5T 2XEiE6b9pIb++52q/HnRuOyeACEP6SjIDgV3FO0YnOj2hVQts2xNPbdOQ5Yopdd6L1Hx xuT4c6dsffCqcnrx2+7BAgjLH2QTrNFW7+8fpRwul8DiwKSWgtKHq6oJ2BLmz16kzM6l Hf+EV59UpucUYdR2PDrEnhdL3FiS5nfAo0a300lStUrxF4YUDFHhXBIRzJjglLux8VJA kziQ==
X-Gm-Message-State: ACgBeo00+cQQ82PCI41R4pz6qk1NHl9hUU+LwskswYb8C+UykSXty8DG UPgf+089Ssug5PvZ+Fm2fIIAAsUkcEpJxR9QW/gJ/IFxo2nbCVGZ7Tofo/3wHPIqfUKkIwVd/Lv gynwvc5dk5UGkYy7lOu0GYq/E4qxXvQyLd8v+ek0GIkTGCm9kj3ed6g==
X-Received: by 2002:a37:5881:0:b0:6b5:75d8:5e83 with SMTP id m123-20020a375881000000b006b575d85e83mr18123437qkb.647.1660078647374; Tue, 09 Aug 2022 13:57:27 -0700 (PDT)
X-Google-Smtp-Source: AA6agR6CHva60OFGXoAHltindnNvulp/StfgfZTIAMX7HEkkrmw7yxkiFgonDUPE9OE4eeFlTgHfJQ==
X-Received: by 2002:a37:5881:0:b0:6b5:75d8:5e83 with SMTP id m123-20020a375881000000b006b575d85e83mr18123417qkb.647.1660078647044; Tue, 09 Aug 2022 13:57:27 -0700 (PDT)
Received: from [192.168.1.74] ([98.47.139.97]) by smtp.gmail.com with ESMTPSA id x19-20020a05620a449300b006b9439332e2sm6861927qkp.13.2022.08.09.13.57.26 for <tls@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Aug 2022 13:57:26 -0700 (PDT)
Message-ID: <2bcd5c96-4595-fbf6-5648-4ec27753ca45@redhat.com>
Date: Tue, 09 Aug 2022 13:57:24 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0
To: tls@ietf.org
References: <CABzBS7nsbEhR-bmHG_ViSJFSH-0_5p0O3vKndS4+wFR=iGQzhw@mail.gmail.com> <CAMm+LwgAzb4t=awzpU4Sb5j7Bf6DuR3u+23n+h_C3Pnsin-SHg@mail.gmail.com> <CH0PR11MB544479BFF3107C532AD75172C1619@CH0PR11MB5444.namprd11.prod.outlook.com> <20220806051105.GP3579@akamai.com> <CAMm+LwhwKW6vmy7vu6Q_8Bg-CNtJyzgPJhKEzo9gP85ktnk75g@mail.gmail.com> <7b8fee1c-686b-5202-d639-af34aa19ebff@cs.tcd.ie> <CAMm+LwhpZbhTxo7Vu9REO50f2cCFbKwUCcuhDVmapam4121g5Q@mail.gmail.com>
From: Robert Relyea <rrelyea@redhat.com>
In-Reply-To: <CAMm+LwhpZbhTxo7Vu9REO50f2cCFbKwUCcuhDVmapam4121g5Q@mail.gmail.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: multipart/alternative; boundary="------------5sSm0xqVXr50qZfUXFb5y2KX"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YYfC7P0m6o98Jflz2jJ2mG65w40>
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: Tue, 09 Aug 2022 20:57:35 -0000

On 8/6/22 11:40 AM, Phillip Hallam-Baker wrote:
> +1
>
> Anything the WG does has to be proof against Quantum Cryptanalysis and 
> LoW (Laptops on Weekends). The fact that the broken algorithms did not 
> get picked does not change the fact that they made it to the third round.

Lumping all the algorithms together is just a strawman. Yes two 
algorithms made it to the 3rd and were broken. The reason Rainbow wasn't 
picked was because it was broken before the end of the 3rd round. 
Multivarient equations sounded good at the beginning, but all forms and 
uses of multivarient have been broken.

Sike was in the 3rd round as an alternate. It was an alternate precisely 
because the idea had the least time in which people work pushing on it. 
I was never going to be picked as the final in this round. The 
algorithms in the alternate list are the precisely because they are 
interesting, but not proven.

Structured Lattice is in between. It's been around a lot longer then 
Multivarient or SIKE, but not as long as ECC, RSA or classic Code Based 
algorithms. It's good to be skeptical, but it's also time to start 
getting experience with it.

>
>
>
>
> On Sat, Aug 6, 2022 at 1:53 PM Stephen Farrell 
> <stephen.farrell@cs.tcd.ie> wrote:
>
>
>
>     On 06/08/2022 17:47, Phillip Hallam-Baker wrote:
>     > Are you proposing pure Kyber or a hybrid though?
>
>     I've not heard anyone suggest securing an IETF protocol
>     only via PQC algs. It'd be incredibly dim to make that
>     suggestion IMO, esp now that two of the 3rd round entries
>     have been busted. So I'm not worried that we'd even come
>     close to landing there for TLS.
>

hybrid is where we should be now. We should have some confidence in 
Kyber, but we have a lot of confidence in RSA and ECC.

The issue of Kyber isn't that 2 3rd round entries were busted. The worry 
is we are still learning about the potential gotcha's of  structured 
lattice. (You thought side channel attacks on RSA were bad, what until 
you  have to implement a secure lattice cypher).

bob

>     S.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email