Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt

"Tobias Guggemos" <guggemos@nm.ifi.lmu.de> Thu, 28 March 2019 08:37 UTC

Return-Path: <guggemos@nm.ifi.lmu.de>
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 4F5CF12015E; Thu, 28 Mar 2019 01:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 E92Zdcz1VGx3; Thu, 28 Mar 2019 01:37:05 -0700 (PDT)
Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8A0312014C; Thu, 28 Mar 2019 01:37:05 -0700 (PDT)
Received: from DESKTOP58DFL8T (unknown [IPv6:2001:67c:370:128:3426:3a2d:57b2:966f]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id B2B3035CE3B; Thu, 28 Mar 2019 09:37:03 +0100 (CET)
From: Tobias Guggemos <guggemos@nm.ifi.lmu.de>
To: "'Panos Kampanakis (pkampana)'" <pkampana@cisco.com>, Tobias Heider <heidert@nm.ifi.lmu.de>, IPsecME WG <ipsec@ietf.org>
Cc: draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org, stefan@gazdag.de
References: <154748799416.9552.17299073748247797491.idtracker@ietfa.amsl.com> <000101d4ad6b$4a790ca0$df6b25e0$@gmail.com> <13654392-83f1-6995-6ca5-f72b2b0be7eb@nm.ifi.lmu.de> <f1510df032fb4588be527ee0f0871d35@XCH-ALN-010.cisco.com>
In-Reply-To: <f1510df032fb4588be527ee0f0871d35@XCH-ALN-010.cisco.com>
Date: Thu, 28 Mar 2019 09:37:02 +0100
MIME-Version: 1.0
Message-ID: <001501d4e541$6b1af230$4150d690$@nm.ifi.lmu.de>
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHua0po1SQdv3p8eF/bRngBUmtvn6V9+0SAgG6isICAAJ1ngIAAboBg
Content-Language: de
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha256"; boundary="=-=UhN+7FVH7zCfYw=-="
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/RutVPso4ScpODVXeK4UkaLcy_9c>
Subject: Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 28 Mar 2019 08:37:08 -0000

> > #4 Big Keys (e.G. Classic McEliece)
> > In general there was consensus that we should find a way to enable the use of McEliece keys.
> > The problem is that McEliece keys are >1MB in size and thus can not fit into the KE payload
> > (which has a 16 bit size field).
> Exchanging such big keys would unnecessarily slow down IKEv2 to a crawl. There are multiple candidates in the NIST PQ Project that offer pk+ct sizes of a few kilobytes. It is likely that some will be standardized. Classic McEliece performance seems much slower than other candidates as well. 
> Sorry I missed it, but why was it decided that supporting Classic McEliece is a must? 

There is no decision made on this, at the end this is a question to be discussed and agreed on in the WG.
However, with McEliece being the proposal which is most trusted in the crypto community, there will be people wanting to support it (let it be governmental institutions with strict security requirements).
We had "consensus" on:
1) that the draft should support the possibility to exchange McEliece keys without "breaking" the protocol again. 
2) we all hope that we won't need it! =)

Correct me if I'm wrong.

> Panos

Cheers Tobias