Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Tero Kivinen <kivinen@iki.fi> Mon, 14 August 2017 13:05 UTC

Return-Path: <kivinen@iki.fi>
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 BF6441321D8 for <ipsec@ietfa.amsl.com>; Mon, 14 Aug 2017 06:05:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXPy-sHyt1qd for <ipsec@ietfa.amsl.com>; Mon, 14 Aug 2017 06:05:32 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 364211321D2 for <ipsec@ietf.org>; Mon, 14 Aug 2017 06:05:28 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v7ED5MkK025966 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Aug 2017 16:05:22 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v7ED5Lmk022509; Mon, 14 Aug 2017 16:05:21 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <22929.40977.702012.485140@fireball.acr.fi>
Date: Mon, 14 Aug 2017 16:05:21 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Daniel Van Geest <Daniel.VanGeest@isara.com>, "ipsec@ietf.org" <ipsec@ietf.org>, "Graham Bartlett (grbartle)" <grbartle@cisco.com>
In-Reply-To: <10412.1502302334@obiwan.sandelman.ca>
References: <BBEB2C9C-9B96-4C6C-BB9B-4415F096FAE1@cisco.com> <B991A75E-0473-428E-95B8-39491D0EB098@isaracorp.com> <10412.1502302334@obiwan.sandelman.ca>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 1 min
X-Total-Time: 1 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/NXZfS5O3H8jTmXKXKefyoyyuIBM>
Subject: Re: [IPsec] Proposed method to achieve quantum resistant IKEv2
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 14 Aug 2017 13:05:34 -0000

Michael Richardson writes:
> I don't think we need to do this.
> I think that unknown transform types will be ignored by compliant
> implementations.

Nope. It will ignore unknown transform IDs for each known transform
type, but it MUST understand each transform type, and if it does not
understand it cannot pick one value for it, thus it must ignore the
whole proposal, and try to use other proposals which might work
better. 
-- 
kivinen@iki.fi