IETF Logo Mail Archive

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

Kris Kwiatkowski <kris@amongbytes.com> Tue, 23 August 2022 08:29 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 5DC16C152597 for <tls@ietfa.amsl.com>; Tue, 23 Aug 2022 01:29:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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
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 lodhWF-PNlAb for <tls@ietfa.amsl.com>; Tue, 23 Aug 2022 01:29:48 -0700 (PDT)
Received: from 8.mo580.mail-out.ovh.net (8.mo580.mail-out.ovh.net [46.105.52.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 5CAFAC14F74B for <tls@ietf.org>; Tue, 23 Aug 2022 01:29:48 -0700 (PDT)
Received: from mxplan8.mail.ovh.net (unknown [10.108.20.22]) by mo580.mail-out.ovh.net (Postfix) with ESMTPS id E2EBD22510 for <tls@ietf.org>; Tue, 23 Aug 2022 08:29:45 +0000 (UTC)
Received: from amongbytes.com (37.59.142.109) by mxplan8.mail.ovh.net (172.16.2.42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.9; Tue, 23 Aug 2022 10:29:45 +0200
Authentication-Results: garm.ovh; auth=pass (GARM-109S003f1ea691e-4008-409c-9f5a-fc8ece9ef8a7, B61D5DB49F45E72D052CEB71467EADE36F3A08F1) smtp.auth=kris@amongbytes.com
X-OVh-ClientIp: 90.251.255.1
Content-Type: multipart/alternative; boundary="------------pD5sfTNI3xrGHjAtIcT7wdWy"
Message-ID: <d33f6c42-0f9d-add0-7e98-57e0ceeaa55f@amongbytes.com>
Date: Tue, 23 Aug 2022 09:29:44 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0
To: tls@ietf.org
References: <27E9945C-6A0A-46DD-89F0-22BE59188216@heapingbits.net> <e43fc649-3fc6-333b-c44d-55de0627c710@cs.tcd.ie> <Ymz7yncQAnzmp/eL@LK-Perkele-VII2.locald> <38de10e6-ab3c-6ea1-44b7-57057c97e7aa@cs.tcd.ie> <CH0PR11MB5444D7D4F32F195FFB189C10C1679@CH0PR11MB5444.namprd11.prod.outlook.com> <320bb3ca-890b-45c9-b55f-f0d65bdce7be@beta.fastmail.com> <CAMjbhoXMb93+hy3jjHS=BnMekyoksSejEjJwpPHN967RAH_acA@mail.gmail.com> <9f513169-7b45-2be0-13fd-b8aa2d2a2280@amongbytes.com> <31cf9ef9-14df-40d1-aa61-1ff366b1f40b@beta.fastmail.com>
From: Kris Kwiatkowski <kris@amongbytes.com>
In-Reply-To: <31cf9ef9-14df-40d1-aa61-1ff366b1f40b@beta.fastmail.com>
X-Ovh-Tracer-GUID: 00be488a-5a0e-47ed-acb0-2597dcc2ba05
X-Ovh-Tracer-Id: 10374323218474909463
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvfedrvdeiledgtdefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpegtkfffgggfuffvfhfhjgesrgdtreertdefjeenucfhrhhomhepmfhrihhsucfmfihirghtkhhofihskhhiuceokhhrihhssegrmhhonhhgsgihthgvshdrtghomheqnecuggftrfgrthhtvghrnhepveffkeegteeugeehudeifffhkeejvddvgefghfdtudfgfeelgeehgeelledufeeknecuffhomhgrihhnpehivghtfhdrohhrghenucfkpheptddrtddrtddrtddpfeejrdehledrudegvddruddtleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhhtpdhhvghlohepmhigphhlrghnkedrmhgrihhlrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpehkrhhishesrghmohhnghgshihtvghsrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepthhlshesihgvthhfrdhorhhgpdfovfetjfhoshhtpehmohehkedt
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CUS_rn_gjIGpTPEcZc8x1j1Od_0>
Subject: Re: [TLS] WGLC 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: Tue, 23 Aug 2022 08:29:52 -0000

On 23/08/2022 01:39, Martin Thomson wrote:
> On Tue, Aug 23, 2022, at 00:11, Kris Kwiatkowski wrote:
>> As X25519 is not FIPS-approved, the lab won't be able to test it,
> OK, hypothetical question, but maybe an important one.
>
> Why would a certification lab care?  We compose secrets with non-secrets all the time, so even if X25519 were replaced with a public value, as long as Kyber is approved, can they not proceed to certify on the basis of the strength of the Kyber algorithm and its implementation?

FIPS lab won't care, as I've mentioned Kyber+x25519 can be certified when Kyber is FIPS-approved. The customers may
care. As FIPS developer, I would like to be able to provide hybrid construction in which both algorithms are FIPS
approved, so that in case Kyber gets broken, the key exchange is still is safe (as per FIPS standards), rather then
Kyber gets broken and now you are not FIPS compliant.
Makes sense?

>
> Or, more realistically, maybe the composition method can be approved, just as composing a secret with "chickenchickenchicken" can be rendered safe.  That way, composing with an arbitrary primitive might be considered safe if the composition method is approved.

Composition method is an approved technique, see SP800-56Cr2 (point 2).

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

v2.23.0 | Report a Bug | By Email