IETF Logo Mail Archive

Re: [TLS] PQC key exchange sizes

"Kampanakis, Panos" <kpanos@amazon.com> Wed, 27 July 2022 02:21 UTC

Return-Path: <prvs=2006fe077=kpanos@amazon.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 D7024C13CCF9 for <tls@ietfa.amsl.com>; Tue, 26 Jul 2022 19:21:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.191
X-Spam-Level:
X-Spam-Status: No, score=-15.191 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 heHj6kYY3yhI for <tls@ietfa.amsl.com>; Tue, 26 Jul 2022 19:21:37 -0700 (PDT)
Received: from smtp-fw-80007.amazon.com (smtp-fw-80007.amazon.com [99.78.197.218]) (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 31272C13CCF8 for <tls@ietf.org>; Tue, 26 Jul 2022 19:21:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1658888497; x=1690424497; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=n1O6ZCWpbCres6krMSZmkksAeCr83Dx3IHXIogkOXfg=; b=cqKANnFueWITk4tf5K+vSARffsxzofocR+Fc43PuM0eARF1hQOpbFxnu 8EBcG87LXZOmtAmg7lPB1tKF66K7bBfRgAuN4kk549uAhmMuy8nTW+qZc 7Y4+6kI6qPVk9a+UvBncz8P7KAejocRIdwb8rt8g+WfQxyTfsnSYkeykL g=;
X-IronPort-AV: E=Sophos;i="5.93,194,1654560000"; d="scan'208";a="112743263"
Thread-Topic: [TLS] PQC key exchange sizes
Received: from pdx4-co-svc-p1-lb2-vlan3.amazon.com (HELO email-inbound-relay-iad-1d-1c3c2014.us-east-1.amazon.com) ([10.25.36.214]) by smtp-border-fw-80007.pdx80.corp.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jul 2022 02:21:20 +0000
Received: from EX13MTAUWB001.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan2.iad.amazon.com [10.40.163.34]) by email-inbound-relay-iad-1d-1c3c2014.us-east-1.amazon.com (Postfix) with ESMTPS id 54349D4540; Wed, 27 Jul 2022 02:21:19 +0000 (UTC)
Received: from EX19D001ANA003.ant.amazon.com (10.37.240.188) by EX13MTAUWB001.ant.amazon.com (10.43.161.207) with Microsoft SMTP Server (TLS) id 15.0.1497.36; Wed, 27 Jul 2022 02:21:18 +0000
Received: from EX19D001ANA001.ant.amazon.com (10.37.240.156) by EX19D001ANA003.ant.amazon.com (10.37.240.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1118.9; Wed, 27 Jul 2022 02:21:17 +0000
Received: from EX19D001ANA001.ant.amazon.com ([fe80::6054:a5f0:5f79:c120]) by EX19D001ANA001.ant.amazon.com ([fe80::6054:a5f0:5f79:c120%5]) with mapi id 15.02.1118.009; Wed, 27 Jul 2022 02:21:17 +0000
From: "Kampanakis, Panos" <kpanos@amazon.com>
To: Martin Thomson <mt@lowentropy.net>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Index: AQHYoQORxutUKrTmV065asnwS2GNUK2Qx2oAgACx2HA=
Date: Wed, 27 Jul 2022 02:21:17 +0000
Message-ID: <acfb870ed4a9461e8b3861a50b346797@amazon.com>
References: <CABzBS7nsbEhR-bmHG_ViSJFSH-0_5p0O3vKndS4+wFR=iGQzhw@mail.gmail.com> <dafc791e-2224-6af1-ae16-7d6996ea8008@cs.tcd.ie> <9f6b11ba-3649-42bb-87e9-1015be3dc84b@www.fastmail.com>
In-Reply-To: <9f6b11ba-3649-42bb-87e9-1015be3dc84b@www.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.43.156.48]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/NZFhynx3XOEnxOC7MSsXIuONlP0>
Subject: Re: [TLS] 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: Wed, 27 Jul 2022 02:21:38 -0000

Hi Martin,

> If we wanted a PQ HPKE (or a Hybrid KEM) then ECH would blow out the size so that we would end up with multiple packets for the CH.  That would be basically unworkable from a performance perspective.

Why are 2-3 packet CHs unworkable? Do you have data to share? 2-3 packets mean higher loss probability, OK. But for a 5% per packet loss probability, a 2 and 3 packet CH would have  9.5% and 14% probability of losing at least one packet which is worse, but imo not that worse.

Note that many academic publications have tested PQ KEMs that blow the CH to 2-3 packets and find performance does not lack that much. OK these papers did not test the "tails", but I am curious if you have any data to substantiate the claim. 




-----Original Message-----
From: TLS <tls-bounces@ietf.org> On Behalf Of Martin Thomson
Sent: Tuesday, July 26, 2022 11:31 AM
To: tls@ietf.org
Subject: RE: [EXTERNAL][TLS] PQC key exchange sizes

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



On Tue, Jul 26, 2022, at 11:21, Stephen Farrell wrote:
> Be interested in how that'd change the CH if ECH is used too.
> I guess the answer mightn't make us happy;-)

PQ HPKE would not fit, but the Kyber-512 numbers mean that we should be OK for ECH if we stuck with classical security.  For obvious reasons, that might not be OK though.

If we wanted a PQ HPKE (or a Hybrid KEM) then ECH would blow out the size so that we would end up with multiple packets for the CH.  That would be basically unworkable from a performance perspective.

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

v2.23.0 | Report a Bug | By Email