IETF Logo Mail Archive

[CFRG] Re: [IPsec] Re: draft-kampanakis-ml-kem-ikev2

"Kampanakis, Panos" <kpanos@amazon.com> Tue, 27 August 2024 15:51 UTC

Return-Path: <prvs=962d3066d=kpanos@amazon.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55521C180B68; Tue, 27 Aug 2024 08:51:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.248
X-Spam-Level:
X-Spam-Status: No, score=-7.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.148, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 zYNtd48URJTN; Tue, 27 Aug 2024 08:51:27 -0700 (PDT)
Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10CA6C1D620D; Tue, 27 Aug 2024 08:51:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1724773887; x=1756309887; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=foebNxONrjZoJWol0hqtcqGs/T+w8uGKq4f2p7Jw06s=; b=nad4rPQM02zDdPbMuXb+ucMHk558e9eGxLGBox2jOBT4CFdQVD+2laD2 by5K2JgIQ9JXbsX1Un05g3Bpyg9L+LZSSSiQXRd9iV7kUUsWSXfVs9cwe vvU72qUPhjdBZgX/gXNQ0LOhpsVpF2hPm59paCMEB3VMBs1d6LdNEyLDY U=;
X-IronPort-AV: E=Sophos;i="6.10,180,1719878400"; d="scan'208,217";a="447986228"
Thread-Topic: [IPsec] Re: draft-kampanakis-ml-kem-ikev2
Received: from pdx4-co-svc-p1-lb2-vlan3.amazon.com (HELO smtpout.prod.us-west-2.prod.farcaster.email.amazon.dev) ([10.25.36.214]) by smtp-border-fw-9102.sea19.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Aug 2024 15:51:19 +0000
Received: from EX19MTAUWC001.ant.amazon.com [10.0.21.151:49276] by smtpin.naws.us-west-2.prod.farcaster.email.amazon.dev [10.0.31.146:2525] with esmtp (Farcaster) id 1321456f-f32d-4c40-a32a-9d8c90b31b7f; Tue, 27 Aug 2024 15:51:18 +0000 (UTC)
X-Farcaster-Flow-ID: 1321456f-f32d-4c40-a32a-9d8c90b31b7f
Received: from EX19D001ANA002.ant.amazon.com (10.37.240.136) by EX19MTAUWC001.ant.amazon.com (10.250.64.174) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.34; Tue, 27 Aug 2024 15:51:18 +0000
Received: from EX19D001ANA001.ant.amazon.com (10.37.240.156) by EX19D001ANA002.ant.amazon.com (10.37.240.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.35; Tue, 27 Aug 2024 15:51:17 +0000
Received: from EX19D001ANA001.ant.amazon.com ([fe80::4f78:75cd:3117:8055]) by EX19D001ANA001.ant.amazon.com ([fe80::4f78:75cd:3117:8055%5]) with mapi id 15.02.1258.035; Tue, 27 Aug 2024 15:51:17 +0000
From: "Kampanakis, Panos" <kpanos@amazon.com>
To: Paul Wouters <paul.wouters=40aiven.io@dmarc.ietf.org>, "Scott Fluhrer (sfluhrer)" <sfluhrer=40cisco.com@dmarc.ietf.org>
Thread-Index: AQHa9+fVqohQdiFqREyibjSTHtDYC7I7P5Cg
Date: Tue, 27 Aug 2024 15:51:17 +0000
Message-ID: <f1c0c0e72673472fb0c0caccc0a6ac7d@amazon.com>
References: <CH0PR11MB54448C7AE123A3D909E4EE1DC18B2@CH0PR11MB5444.namprd11.prod.outlook.com> <CAGL5yWajZ5-iJWN1iWiYZUxMemv=cm+3tcqodbA4+nfW5y4oPg@mail.gmail.com>
In-Reply-To: <CAGL5yWajZ5-iJWN1iWiYZUxMemv=cm+3tcqodbA4+nfW5y4oPg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.106.239.22]
Content-Type: multipart/alternative; boundary="_000_f1c0c0e72673472fb0c0caccc0a6ac7damazoncom_"
MIME-Version: 1.0
Message-ID-Hash: AJGTFYCAHPHWEJZ26RF2AIIICJVPBWYA
X-Message-ID-Hash: AJGTFYCAHPHWEJZ26RF2AIIICJVPBWYA
X-MailFrom: prvs=962d3066d=kpanos@amazon.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "ipsec@ietf.org" <ipsec@ietf.org>, "cfrg@ietf.org" <cfrg@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [CFRG] Re: [IPsec] Re: draft-kampanakis-ml-kem-ikev2
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/YTn3ltV3mffz4DZbgd206voEZVE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Owner: <mailto:cfrg-owner@irtf.org>
List-Post: <mailto:cfrg@irtf.org>
List-Subscribe: <mailto:cfrg-join@irtf.org>
List-Unsubscribe: <mailto:cfrg-leave@irtf.org>

CFRG had https://datatracker.ietf.org/doc/draft-cfrg-schwabe-kyber/ , https://bwesterb.github.io/draft-schwabe-cfrg-kyber/draft-cfrg-schwabe-kyber.html for Kyber, but that was for the draft00 versions of Kyber deployed in early TLS 1.3 codepoints. I believe the official spec for ML-KEM will be FIPS 203.


I am not sure we definately need a ML-KEM CFRG doc, although it would be better. We could have a normative reference to an external spec like RFC8422<https://www.rfc-editor.org/rfc/rfc8422> which said
> The named curves secp256r1, secp384r1, and secp521r1 are

> specified in SEC 2 [SECG-SEC2<https://www.rfc-editor.org/rfc/rfc8422#ref-SECG-SEC2>]  These curves are also recommended in
> ANSI X9.62 [ANSI.X9-62.2005<https://www.rfc-editor.org/rfc/rfc8422#ref-ANSI.X9-62.2005>] and FIPS 186-4 [FIPS.186-4<https://www.rfc-editor.org/rfc/rfc8422#ref-FIPS.186-4>]

Personally, I would prefer to have a ratified RFC like Scott. But in all honesty, I would not want it if it means we have to wait 2-3 years without codepoints in order to get a CFRG document ratified and then an IPSECME document ratified.


From: Paul Wouters <paul.wouters=40aiven.io@dmarc.ietf.org>
Sent: Monday, August 26, 2024 2:43 PM
To: Scott Fluhrer (sfluhrer) <sfluhrer=40cisco.com@dmarc.ietf.org>
Cc: ipsec@ietf.org; cfrg@ietf.org
Subject: [EXTERNAL] [IPsec] Re: draft-kampanakis-ml-kem-ikev2


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 Mon, Aug 26, 2024 at 1:51 PM Scott Fluhrer (sfluhrer) <sfluhrer=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:
I (and I don’t believe I am alone in this) would like to see an ML-KEM RFC for IKE; how can we make it happen?

From what I see, the next step (now that the authors have updated it to specify the final version of ML-KEM) would be having it adopted by the working group (and while there are a number of steps past that, I don’t know if those can proceed before this initial step).

Is this something that can be done before Dublin?

Is CFRG going to have an "how to use ML-KEM in IETF protocols" document, like it did with RFC 7748 and RFC 7539 ?

I would personally feel much better if there was such a guidance document, before we finalize the specification at the various protocols itself.

Paul

v2.46.0 | Report a Bug | By Email | System Status