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 <gugge...@nm.ifi.lmu.de> 
Sent: Thursday, March 28, 2019 4:37 AM
To: Panos Kampanakis (pkampana) <pkamp...@cisco.com>; Tobias Heider 
<heid...@nm.ifi.lmu.de>; IPsecME WG <ipsec@ietf.org>
Cc: draft-tjhai-ipsecme-hybrid-qske-ik...@ietf.org; ste...@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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to