IETF Logo Mail Archive

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

"Panos Kampanakis (pkampana)" <pkampana@cisco.com> Thu, 28 March 2019 13:19 UTC

Return-Path: <pkampana@cisco.com>
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 DFD6B1202AE; Thu, 28 Mar 2019 06:19:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 XMOmghKOIjF2; Thu, 28 Mar 2019 06:19:09 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E899812024A; Thu, 28 Mar 2019 06:19:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2912; q=dns/txt; s=iport; t=1553779149; x=1554988749; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7CWqPnzB/btQV2qMUTVHsB9DyDOiT0DDFTDo1Qdn3aU=; b=jSjvEOcwLkkseqqskdcGbkzBkcm5ZFMx4VFas7bDb8+BVAXrUU1NUU2b BI6E1ZOXG5v2kytWuibNsN+oGC/do94BupsLrguS0TUUGvBsnANS6Rc47 x5qDUEpEUR1b4u/w2HnnsNEzrrJYTPZhkHI4+ZpRWEF9aJmiS70vJFOEh c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAABzyZxc/5FdJa1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBghCBaycKhASIHI0vmDyBew0BAYRsAheFGyI0CQ0BAQMBAQkBAwJtKIVKAQEBAwEjEUMCBQcEAgEIEQQBAQMCJgICAjAVCAgCBAENBQgMhHwIqgOBL4ovgQskAYltgUQXgUA/gRGDEj6HToJXA4x5mDIJApM9IpQMiyyTOgIRFYEuHziBVnAVgyeCQI4LQTGOVoEfAQE
X-IronPort-AV: E=Sophos;i="5.60,280,1549929600"; d="scan'208";a="251647618"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Mar 2019 13:19:08 +0000
Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x2SDJ7Pk001884 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Mar 2019 13:19:07 GMT
Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 28 Mar 2019 08:19:07 -0500
Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1473.003; Thu, 28 Mar 2019 08:19:07 -0500
From: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
To: Tobias Guggemos <guggemos@nm.ifi.lmu.de>, Tobias Heider <heidert@nm.ifi.lmu.de>, IPsecME WG <ipsec@ietf.org>
CC: "draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org" <draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org>, "stefan@gazdag.de" <stefan@gazdag.de>
Thread-Topic: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt
Thread-Index: AQHua0powokFFDmjq0KUYKKplIZSzqV9+0SAgG6isICAAJ1ngIAAboBggABNmqA=
Date: Thu, 28 Mar 2019 13:19:07 +0000
Message-ID: <9a64907bac864d238e81d0d3dcf4c4bb@XCH-ALN-010.cisco.com>
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> <001501d4e541$6b1af230$4150d690$@nm.ifi.lmu.de>
In-Reply-To: <001501d4e541$6b1af230$4150d690$@nm.ifi.lmu.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.230.81]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/RUIXZeREcJkIQ4X4e-DcxD3LbJ4>
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 13:19:14 -0000

Thanks Tobias, Valery and Stefan. 

Imo Classic McEliece is impractical for use in live key negotiations in protocols like TLS, IKE, SSH etc. NIST will standardize more practical and secure postquantum KEMs and the added complexity for McEliece is not necessary. I understand that others might want McEliece because they trust it more. In that case, I suggest the mechanism described in #6 to be a "MAY" in the draft. 

Panos



-----Original Message-----
From: Tobias Guggemos <guggemos@nm.ifi.lmu.de> 
Sent: Thursday, March 28, 2019 4:37 AM
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
Subject: AW: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt

* PGP Signed by an unknown key

> > #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

* Unknown Key
* 0xC833559F

v2.23.0 | Report a Bug | By Email