Re: [TLS] PQC key exchange sizes

"Kampanakis, Panos" <kpanos@amazon.com> Wed, 27 July 2022 02:27 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 2E9A9C14CF01 for <tls@ietfa.amsl.com>; Tue, 26 Jul 2022 19:27:18 -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 X0pnMm1x6zAN for <tls@ietfa.amsl.com>; Tue, 26 Jul 2022 19:27:16 -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 B1A35C13CCF9 for <tls@ietf.org>; Tue, 26 Jul 2022 19:27:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1658888837; x=1690424837; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=N0hM+YplARl8aUXr4G4cGjTMN2Anp87vJWFO9fl3Bv8=; b=axjOh2bX0q43hrWMNpzr3/POGDUxQh5sVMSjtiWJPCTa0vtkT3JHZuBX bPcu4uOk/4VHt1GMvQx14c7q/D6/rKngWBoHOO/VBc5h1AfLI4YnmhvmM 99x6Gk89vle7R+Sh3YlYKGmIVf4X+M2De253fhVOMX3ym4p89SAuAqTcu A=;
X-IronPort-AV: E=Sophos;i="5.93,194,1654560000"; d="scan'208";a="112744215"
Thread-Topic: [TLS] PQC key exchange sizes
Received: from pdx4-co-svc-p1-lb2-vlan3.amazon.com (HELO email-inbound-relay-iad-1a-828bd003.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:27:16 +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-1a-828bd003.us-east-1.amazon.com (Postfix) with ESMTPS id D3BFE803CE; Wed, 27 Jul 2022 02:27:14 +0000 (UTC)
Received: from EX19D001ANA004.ant.amazon.com (10.37.240.187) by EX13MTAUWB001.ant.amazon.com (10.43.161.249) with Microsoft SMTP Server (TLS) id 15.0.1497.36; Wed, 27 Jul 2022 02:27:13 +0000
Received: from EX19D001ANA001.ant.amazon.com (10.37.240.156) by EX19D001ANA004.ant.amazon.com (10.37.240.187) 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:27:12 +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:27:12 +0000
From: "Kampanakis, Panos" <kpanos@amazon.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Index: AQHYoQFNhppuch2xgEOt7202I6P1U62Rfakg
Date: Wed, 27 Jul 2022 02:27:12 +0000
Message-ID: <a643450d5fdb40cf8af3f5b96cdbd922@amazon.com>
References: <CABzBS7nsbEhR-bmHG_ViSJFSH-0_5p0O3vKndS4+wFR=iGQzhw@mail.gmail.com> <YuABORXSaes9Wqwo@LK-Perkele-VII2.locald>
In-Reply-To: <YuABORXSaes9Wqwo@LK-Perkele-VII2.locald>
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/18PdChMSeRscPbZiE1yQ_KBxA7o>
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:27:18 -0000

Hi Ilari,

> - DTLS-level fragmentation. There are buggy implementations that break if one tries this.

DTLS servers have been fragmenting and sending cert chains that don’t fit in the MTU for a long time. Is this buggy on the TLS client side? Any public info you can share about these buggy implementations for my education?



-----Original Message-----
From: TLS <tls-bounces@ietf.org> On Behalf Of Ilari Liusvaara
Sent: Tuesday, July 26, 2022 10:59 AM
To: <tls@ietf.org> <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 02:15:34PM +0200, Thom Wiggers wrote:
>
> In yesterday’s working group meeting we had a bit of a discussion of 
> the impact of the sizes of post-quantum key exchange on TLS and 
> related protocols like QUIC. As we neglected to put Kyber’s key sizes 
> in our slide deck (unlike the signature schemes), I thought it would 
> be a good idea to get the actual numbers of Kyber onto the mailing list.
>
> Note that in the context of TLS’s key exchange, the public key would 
> be what goes into the ClientHello key_shares extension, and the 
> ciphertext would go into the Server’s ServerHello key_shares extension.
>
> Kyber512: NIST level I, "strength ~AES128"
>   public key: 800 bytes
>   ciphertext: 768 bytes
>   secret key: 1632 bytes
> Kyber768: NIST level III, "~AES192"
>   public key: 1184
>   ciphertext: 1088
>   secret key: 2400 bytes
> Kyber1024: NIST level V, "~AES256"
>   public key: 1568
>   ciphertext: 1568
>   secret key: 3168
>
> So for the key exchange at least, it seems to me Kyber512 should work 
> for TLS and QUIC just fine; Kyber768 might be a bit of a squeeze if 
> you want to stay in QUIC’s default 1300 byte initial packet? Also, I 
> don't really know how the D of DTLS might change the story.

The initial packet size is 1200, so Kyber768 public key does not fit into a packet. However, the initial packets can be split, so even
Kyber1024 key does fit into two initial packets (this also doubles the server initial window from 3600 to 7200 due to the way amplification limit works)


DTLS is a bit more problematic. There are two ways to deal with the key being too big to fit in a single IP packet.

- IP-level fragmentation. REALLY SHOULD NOT be used.
- DTLS-level fragmentation. There are buggy implementations that break
  if one tries this.

And in both case, the failure modes are not easy to recover from.




-Ilari

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