IETF Logo Mail Archive

Re: [IPsec] draft-ietf-ipsecme-ikev2-multiple-ke new

Valery Smyslov <svan@elvis.ru> Tue, 11 April 2023 15:00 UTC

Return-Path: <svan@elvis.ru>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E995C1524DD; Tue, 11 Apr 2023 08:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=elvis.ru
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 xXpn7GuD2Jd8; Tue, 11 Apr 2023 08:00:35 -0700 (PDT)
Received: from akmail.elvis.ru (akmail.elvis.ru [82.138.51.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75CFCC1524DE; Tue, 11 Apr 2023 08:00:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=elvis.ru; s=mail; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:CC:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=mUddqC9zCoF0xjvjPo1kqv098m/AutJLzFs3VfCUE3w=; b=gCCuUajOWQzPX1tRy8kA/UES6m q0pjvCtD4uWJvY1CvezJX5oXQZa+nFO1QazcJjqOYmVRVfiaJYyyve/IPLdoY83qZxk/tbPFsj6T0 WWfL6fWX6NDUgE3Q9mYZ1FsGrgdCbNDCJbUtc0IJ4sNb2pt0cpgj4WR1fuMItVhpEJZU=;
Received: from kmail.elvis.ru ([93.188.44.208]) by akmail.elvis.ru with esmtp (Exim 4.92) (envelope-from <svan@elvis.ru>) id 1pmFTw-0001UV-FB; Tue, 11 Apr 2023 18:00:28 +0300
Received: from mail16.office.elvis.ru ([10.111.1.29] helo=mail.office.elvis.ru) by kmail.elvis.ru with esmtp (Exim 4.92) (envelope-from <svan@elvis.ru>) id 1pmFTw-0005MD-8q; Tue, 11 Apr 2023 18:00:28 +0300
Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Tue, 11 Apr 2023 18:00:28 +0300
Received: from buildpc (10.111.10.33) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Tue, 11 Apr 2023 18:00:28 +0300
From: Valery Smyslov <svan@elvis.ru>
To: "'Kampanakis, Panos'" <kpanos@amazon.com>, draft-ietf-ipsecme-ikev2-multiple-ke@ietf.org
CC: ipsec@ietf.org
References: <8c260d5fc73e44aebfc5dfda6e5baf94@amazon.com> <010a01d96c42$41cd5f80$c5681e80$@elvis.ru> <3972849df01f42568601db68778e3849@amazon.com>
In-Reply-To: <3972849df01f42568601db68778e3849@amazon.com>
Date: Tue, 11 Apr 2023 18:00:28 +0300
Message-ID: <019601d96c86$5ac86400$10592c00$@elvis.ru>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0197_01D96C9F.801797D0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJmzJTjdTyygGARgy4SGJWnQGrMxgJZeH9RAf6+B4Ct6K/1QA==
Content-Language: ru
X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru
X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru
X-KLMS-AntiSpam-Interceptor-Info: not scanned
X-KLMS-Rule-ID: 1
X-KLMS-Message-Action: clean
X-KLMS-AntiSpam-Status: not scanned, disabled by settings
X-KLMS-AntiPhishing: Clean, bases: 2023/02/21 22:47:00
X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2023/02/21 21:02:00 #20887462
X-KLMS-AntiVirus-Status: Clean, skipped
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/yfLF99rGgpi-eHkUMoDd5vgC1ZM>
Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-multiple-ke new
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Apr 2023 15:00:40 -0000

I think that an individual draft is OK. 

 

That said, I believe that it should be known to the ipsec community

(e.g. be announced and preferably discussed, even a bit, in the ML).

 

Regards,

Valery.

 

Thanks Valery. Makes sense. 

 

> This may be a very short document referencing generic Kyber specification and clarifying implementation details for IKEv2 (e.g.
the format of the public key etc.).

 

Would that be a draft towards ratification in IPSECME or something like
https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00 which does not need to be ratified and can just serve as the
"Specification Required" for the TLS 1.3 IANA registry?

 

 

From: Valery Smyslov <svan@elvis.ru> 
Sent: Tuesday, April 11, 2023 2:53 AM
To: Kampanakis, Panos <kpanos@amazon.com>; draft-ietf-ipsecme-ikev2-multiple-ke@ietf.org
Cc: ipsec@ietf.org
Subject: RE: [EXTERNAL]draft-ietf-ipsecme-ikev2-multiple-ke new 

 


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.

 

Hi Panos,

 

Hi draft-ietf-ipsecme-ikev2-multiple-ke authors, ipsecme WG,

 

We have seen attempts to get early codepoints allocated for PQ-hybrid key exchanges in TLS 1.3 and HPKE in other IETF WGs. These, I
think, are are good steps. Note for these IANA registries the requirement is "Specification Required". 

 

How about new PQ Transform Type 4 identifiers in IKEv2? Currently the draft-ietf-ipsecme-ikev2-multiple-ke draft says

     It is assumed that new Transform Type 4 identifiers will be assigned later for various post-quantum key exchanges [
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-multiple-ke-12> IKEV2TYPE4ID].

 

So, if draft-ietf-ipsecme-ikev2-multiple-ke will not assign new identifiers for Kyber-768 in
<https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8>
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8, should we be asking the Experts (Tero,
Valery) consider a new allocation?

 

          Yes, that's correct. 

          

          However, while it is possible to ask IANA for new allocation without any referencing document,

          as designated expert I would be much more comfortable if some document (even I-D) exists describing

          how to use Kyber-768 in specific environment of IKEv2. This may be a very short document referencing 

          generic Kyber specification and clarifying implementation details for IKEv2 (e.g. the format of the public key etc.).

 

          Regards,

          Valery.

 

Thx,

Panos

v2.23.0 | Report a Bug | By Email