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

Tero Kivinen <kivinen@iki.fi> Wed, 09 August 2017 09:42 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 F16091320CF for <ipsec@ietfa.amsl.com>; Wed, 9 Aug 2017 02:42:36 -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 OaDBc0u8lLlV for <ipsec@ietfa.amsl.com>; Wed, 9 Aug 2017 02:42:34 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 D21451320BB for <ipsec@ietf.org>; Wed, 9 Aug 2017 02:42:33 -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 v799gNUr027842 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 9 Aug 2017 12:42:23 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v799gN2d009617; Wed, 9 Aug 2017 12:42:23 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <22922.55551.190123.31763@fireball.acr.fi>
Date: Wed, 09 Aug 2017 12:42:23 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Valery Smyslov <svanru@gmail.com>
Cc: "'Graham Bartlett (grbartle)'" <grbartle@cisco.com>, ipsec@ietf.org
In-Reply-To: <041b01d30d21$8d33f230$a79bd690$@gmail.com>
References: <BBEB2C9C-9B96-4C6C-BB9B-4415F096FAE1@cisco.com> <041b01d30d21$8d33f230$a79bd690$@gmail.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 3 min
X-Total-Time: 2 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/Hb48RRAyEW5lhJIHWAGDhqR4AY8>
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: Wed, 09 Aug 2017 09:42:37 -0000

Valery Smyslov writes:
> It is not clear for me (and I raised this concern in Prague) why do
> you use QSKE as an additional Key Exchange mechanism instead of
> replacing DH KE with it? We’ve been being told by cryptographers
> that conventional public key cryptography won’t provide security in
> presence of QC, so why bother with it?

For me the main reason is that we have been told that current protocol
used in IKE is safe, and if we do not break it (i.e., remove it), but
instead just add some more random data to SKEYSEED, I think it should
be quite easy to proove that this new construct is also safe. I.e., us
adding PPK/QSKE etc stuff to our calculations will not weaken the
security of the IKEv2. 

> The only reason that comes to my mind is that you don’t fully trust
> QSKE. Are there any other reasons?

I think that is one of the main reasons. Especially as we do not know
which QSKE we are talking about.
-- 
kivinen@iki.fi