[TLS] Re: draft-connolly-tls-mlkem-key-agreement

Andrey Jivsov <crypto@brainhub.org> Fri, 06 December 2024 20:44 UTC

Return-Path: <brainhubr@gmail.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 823ABC14F617 for <tls@ietfa.amsl.com>; Fri, 6 Dec 2024 12:44:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Level:
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=no 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 ZmFb7ZeQYKar for <tls@ietfa.amsl.com>; Fri, 6 Dec 2024 12:44:27 -0800 (PST)
Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A12C1519AA for <tls@ietf.org>; Fri, 6 Dec 2024 12:44:27 -0800 (PST)
Received: by mail-oi1-f169.google.com with SMTP id 5614622812f47-3ea427001c5so1534882b6e.3 for <tls@ietf.org>; Fri, 06 Dec 2024 12:44:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733517866; x=1734122666; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eDsBoQbYReuHx5NzcrmspFQJ2gbdyhuTNwqwe3wzRKM=; b=QTM9XlnIQijEFjik42e8Tpt1tbV4g8QZaH4cAT4OBfvHESfCAkQGANITXFXUKaDPoo z82BQFNWHQU4iEy8bw15dgYR3f7x0jpW5LvK8s/SdlpuQa7puZEzTqKA7E/OZPW2EkVb cI7VFOaUEHkR9Yr1zqcqDLbPl3doarg3nslhojScRVBBs2B3bmjdnNtqRd/0dK1e2HQ8 +cVY0qIY2toLDc47OBLnV7jcERpUHrt/++vuNfiyG6xG5kocJZVezBI11wgmS/KeHPpv 2VDDPk3PNCLQPrzFTne39eX7AzvA+dKJXV8dAhlZlGr9+KDgP0B+7Ia1hm2xcvUArLQ/ XzjA==
X-Gm-Message-State: AOJu0YzNdq5dCWVQD9AU+U1h08wfBm6VDoV4ZxHBs9ShhOezEnz0PZyk i8DDk+lIrqMOcvrxDT31JcUddvJO1WMXj5WLu8p6RXbT9RupNG+0aHudyQ==
X-Gm-Gg: ASbGnctWbosRIY7MgqNZ0RUG1lb2/P744CKgniDmglnWTqDX/XCt8A9GFHV99KRMpr+ DnCmp3EPWf1oPAeKNtr3RT+nE669U0eMSYDjo/3kX8b0IkpDJ2a7b0nxm3Jo5Z17j1t+r8y0saC KW5dDfDeL/iDX/Wg1bOD69MaXTzN8XgErlw8NAJHMdF1SNlgE24eK+4DfwAJfXCziZNOjoQ+BGW f4J+dUEJlZ24uTp47bM46kHHDbcu2wHLb3jqIkGAlsmlHIn2QnovX2b4gHw2203w5puTPpmjAa6 0kjjf338DMeG7R8=
X-Google-Smtp-Source: AGHT+IHrjvjNjDwaraXoHyzTV08WbqPSDRCA0q4Ba6g2byYvFipZ8bz4AkhkHpsbfDxvVllUxEZgPw==
X-Received: by 2002:a05:6808:10cb:b0:3eb:96e:dcc5 with SMTP id 5614622812f47-3eb19d2d4edmr4303688b6e.25.1733517866451; Fri, 06 Dec 2024 12:44:26 -0800 (PST)
Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com. [209.85.160.172]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6d8da66dda7sm22980706d6.21.2024.12.06.12.44.26 for <tls@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Dec 2024 12:44:26 -0800 (PST)
Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-46741855f9bso2575751cf.2 for <tls@ietf.org>; Fri, 06 Dec 2024 12:44:26 -0800 (PST)
X-Received: by 2002:ac8:5a12:0:b0:461:22f0:4f83 with SMTP id d75a77b69052e-46734efa632mr72238301cf.43.1733517866086; Fri, 06 Dec 2024 12:44:26 -0800 (PST)
MIME-Version: 1.0
References: <CH0PR11MB5444342A5C29C5C5BCCF9BA3C1302@CH0PR11MB5444.namprd11.prod.outlook.com> <20241206172906.124753.qmail@cr.yp.to>
In-Reply-To: <20241206172906.124753.qmail@cr.yp.to>
From: Andrey Jivsov <crypto@brainhub.org>
Date: Fri, 06 Dec 2024 12:44:14 -0800
X-Gmail-Original-Message-ID: <CAAWw3RinB6WKCzLaFjds63Mgoykt-2haaD9rQEsFv2k_b8RJzw@mail.gmail.com>
Message-ID: <CAAWw3RinB6WKCzLaFjds63Mgoykt-2haaD9rQEsFv2k_b8RJzw@mail.gmail.com>
To: "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009ec3660628a01424"
Message-ID-Hash: U77NXX4JEES5J54E5SOWPOZTNFZCQPMK
X-Message-ID-Hash: U77NXX4JEES5J54E5SOWPOZTNFZCQPMK
X-MailFrom: brainhubr@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: draft-connolly-tls-mlkem-key-agreement
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xrH8SQKudJMyzDfgG0NU1Q1GRj8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

I second D.J. Bernstein's concerns, but my other issue with giving options
like this is that they will creep up into MTI sets or default sets, with
higher priority than hybrids.

I find it less ideal that the document on pure ML-KEM (or signature) and
hybrids are disassociated, causing the progress of standardization of the
pure version to bring these other concerns.

So, as long as everyone is on the same page that pure is just one option,
perhaps for strict compliance with CNSA 2.0, then there is no issue from my
perspective, but that's a (mildly) controversial part.

On Fri, Dec 6, 2024 at 9:29 AM D. J. Bernstein <djb@cr.yp.to> wrote:

> Scott Fluhrer (sfluhrer) writes:
> > I understand that people want to discuss the hybrid KEM draft more
> > (because there are more options there) - can we at least get the less
> > controversial part done?
>
> See https://blog.cr.yp.to/20240102-hybrid.html. Using just PQ, rather
> than ECC+PQ, would incur security risks without improving deployment.
> Regarding "less controversial", you might have missed previous TLS WG
> messages such as
>
>     https://mailarchive.ietf.org/arch/msg/tls/j1qkfNmk33OZ7hgCR53TiLmYOiA/
>     https://mailarchive.ietf.org/arch/msg/tls/I1GPuKLCBJ3jA-ovNcuIsLlNGkM/
>     https://mailarchive.ietf.org/arch/msg/tls/gB55YMMdfFLqaCE9ughNXX8qjtA/
>
> where various people (including me, obviously) already objected. Also,
> you might have missed BSI writing in
>
>
> https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile
>
> that its post-quantum KEM recommendations are only "in combination with
> a classical key derivation mechanism"; commentator Matt Green writing in
>
>     https://x.com/matthew_d_green/status/1742521204026622011
>
> that NSA's "stance against hybrid encryption makes absolutely zero
> sense"; and NSA itself in
>
>
> https://web.archive.org/web/20220524232250/https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/threat-prevention.pdf
>
> asking for two cryptographic layers "to mitigate the ability of an
> adversary to exploit a single cryptographic implementation".
>
> ---D. J. Bernstein
>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>