Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

Krzysztof Kwiatkowski <kris@amongbytes.com> Sat, 01 April 2023 02:50 UTC

Return-Path: <kris@amongbytes.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 A1D82C14CF18 for <tls@ietfa.amsl.com>; Fri, 31 Mar 2023 19:50:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 T3sfUv8bo9Ab for <tls@ietfa.amsl.com>; Fri, 31 Mar 2023 19:50:53 -0700 (PDT)
Received: from 1.mo580.mail-out.ovh.net (1.mo580.mail-out.ovh.net [178.33.252.199]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D98C5C14CF13 for <tls@ietf.org>; Fri, 31 Mar 2023 19:50:52 -0700 (PDT)
Received: from mxplan8.mail.ovh.net (unknown [10.108.20.88]) by mo580.mail-out.ovh.net (Postfix) with ESMTPS id A4AEF26960; Sat, 1 Apr 2023 02:50:50 +0000 (UTC)
Received: from amongbytes.com (37.59.142.107) by mxplan8.mail.ovh.net (172.16.2.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Sat, 1 Apr 2023 04:50:49 +0200
Authentication-Results: garm.ovh; auth=pass (GARM-107S001f7888cfa-e911-4d38-b0c2-bbc434afc1a9, 0F43EDA8EE1B16A9550701344A04493BB6A8DC5E) smtp.auth=kris@amongbytes.com
X-OVh-ClientIp: 116.84.110.41
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\))
From: Krzysztof Kwiatkowski <kris@amongbytes.com>
In-Reply-To: <ZCUoRUuJQ55I7qJ4@LK-Perkele-VII2.locald>
Date: Sat, 01 Apr 2023 10:50:04 +0900
CC: "tls@ietf.org" <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID: <A9B55B7A-C352-4880-9A66-13664D461EAB@amongbytes.com>
References: <6cf86afa53f348c69d5a22ed50ae6d4b@amazon.com> <7B644960-382D-4270-95E8-CE5637347A62@ll.mit.edu> <ZCUoRUuJQ55I7qJ4@LK-Perkele-VII2.locald>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Ovh-Tracer-GUID: 86feb65b-1c46-4868-ab50-9ad20b1d1928
X-Ovh-Tracer-Id: 11243799420035121050
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrvdeivddgieehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurheptggguffhjgffvefgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpefmrhiihihsiihtohhfucfmfihirghtkhhofihskhhiuceokhhrihhssegrmhhonhhgsgihthgvshdrtghomheqnecuggftrfgrthhtvghrnhephfetkeekkeeggeeluefgtddukedvffelhedugfffvedvieduvdekheetfeejgedvnecukfhppedtrddtrddtrddtpdduudeirdekgedruddutddrgedupdefjedrheelrddugedvrddutdejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpohhuthdphhgvlhhopehmgihplhgrnhekrdhmrghilhdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepkhhrihhssegrmhhonhhgsgihthgvshdrtghomhdpnhgspghrtghpthhtohepuddprhgtphhtthhopehtlhhssehivghtfhdrohhrghdpoffvtefjohhsthepmhhoheektd
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ym2gLmEsCpVyvXQfx75foyZcPmc>
Subject: Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design
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: Sat, 01 Apr 2023 02:50:53 -0000

> I would pair secp384r1 with Kyber768 for completely different reasons:
> Kyber768 is what the team kyber recommends.
Agreed.

> I don't think there are very good reasons for NIST curves here outside
> wanting CNSA1 compliance, and for that you need secp384r1 classical
> part. And for that, I would pick secp384r1_kyber768.
> 
From my perspective, the two reasons for including a NIST curves are:
1. To have an option for those who require FIPS compliance. In a short term at least one key agreement scheme should be FIPS-approved. In the long term both of them should be fips-approved. That way, in case security of Kyber768 falls below 112-bits or simply implementation is broken, one can still run key agreement in FIPS compliant manner. In the end, the ultimate goal of hybrid-tls draft is to ensure that at least one of the schemes provides security if the other gets broken. Would be good to use this in FIPS context also.
2. NIST curves are more often implemented in HW than Curve25519. When working with chips like ATECC608B, one ideally only adds SW-based Kyber and can reuse existing HW-based ECDH. Such migration is simpler, less risky and time-consuming than adding SW-based X25519.

To accelerate migration, the hybrid-tls draft should move forward rather quickly and be useful variety of use-cases. Hence, I suggest we assign two codepoints one for X25519-Kyber768 and the other for ECDH/p256-Kyber768. X25519 and P256 provide same security level, from my old days in Cloudflare I remember both schemes were used quite often in TLS, so I hope this choice is not to controversial.

Regarding CNSA, I've no experience with national security systems, but does it actually allows to use hybrid schemes? it seems to me that neither 1.0 nor 2.0 allows usage of hybrid schemes (SP800-56C is mentioned but in regards to ECDH, not KDF). Maybe those needs can be addressed at later stage?

Kind regards,

---
Kris Kwiatkowski
Staff Cryptography Architect
PQShield