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

"Valery Smyslov" <smyslov.ietf@gmail.com> Thu, 28 March 2019 08:51 UTC

Return-Path: <smyslov.ietf@gmail.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 6D8A5120243; Thu, 28 Mar 2019 01:51:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8dUFS0HkEfVh; Thu, 28 Mar 2019 01:51:13 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86BB712012B; Thu, 28 Mar 2019 01:51:13 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id o10so6701973wmc.1; Thu, 28 Mar 2019 01:51:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=yoGBagMczplM/PeBgg+3bvQDGUCPzT1kCgVKjTn73h4=; b=fUx0WA9MW12Hk8RcSsEtHANmCX4vmsXJdR2/6xIaD1/NfJmL8wx52vbm9cg+PYirla UG4WSU9OZghkxL4vwlJlIi8OmvhXgBeVrFqRsiNX2X1GIpDjIgxA8M6pgle3VX6AK0/X ENszir3kDkZUwz1FT2uVf7g2jQn/O4Izv/uhm6aPHEEKWpThqqZKQBsg/zTIVPAv8viy YRCj3lRe+zhEcXn9sccRHS4kFxjcb0QpY1IYFVJI9A6ArhjXPDSbdykgGAXMoaVKRrll VdwOZinLBS2o4Velg4RSe2BAMaIkU7NhKvj9W7cPBtvP5BE3Ht33ELEVKwn1z96WBHer hGbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=yoGBagMczplM/PeBgg+3bvQDGUCPzT1kCgVKjTn73h4=; b=lJjtlpOOLgXIHWR8yjAAA+Ys6+KyGkUnhXj74FRxfRlhj8Ky35ZK4tb0PGl5idXH5Y OsuOQ0TuP7swUE2AbbQgvWLziFH7dk/T14f1SPVom6LXhNIVGw8G0D+rcouF6renhko5 fk0S3nSmV9hvsZQKLbuQCCExIJjng7KbdFhygnnwLw3NBI81N8iq2m3wmWdzQPEAI6Lo WiF8tnYkZMZmUy/JpTmheKp4Wv0U484BLPWcgE7RA9NZDHPdJX+I+/Hp0TypsM3LJRxp 4gub4+EiuaA4z5kC+PsJ5i2nDr9dq09sGEEVXtCg503Qyx379hA0wkEKrEWj2WxzRy2c I+cA==
X-Gm-Message-State: APjAAAWWrHodJBvuU0WpNtQVSWVPpp/sM34S/OikVLutQLVXjeUIFEbU 2h0p/79WgNc04pWlIGtoWuOGIcMeHFE=
X-Google-Smtp-Source: APXvYqzudkrOTAmLe2KTSCRF/if3eAoxmhC/HEeAhuMhj/kMdKRkZQUgWmo9/NBOJDrTgka19SN8aw==
X-Received: by 2002:a1c:1c5:: with SMTP id 188mr14345372wmb.52.1553763071711; Thu, 28 Mar 2019 01:51:11 -0700 (PDT)
Received: from svannotebook ([2001:67c:370:128:4cf6:eead:b0ec:3915]) by smtp.gmail.com with ESMTPSA id x17sm55521186wrd.95.2019.03.28.01.51.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 01:51:10 -0700 (PDT)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Tobias Guggemos' <guggemos@nm.ifi.lmu.de>, "'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> <001501d4e541$6b1af230$4150d690$@nm.ifi.lmu.de>
In-Reply-To: <001501d4e541$6b1af230$4150d690$@nm.ifi.lmu.de>
Date: Thu, 28 Mar 2019 11:51:09 +0300
Message-ID: <01ba01d4e543$644a0890$2cde19b0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: ru
Thread-Index: AQHua0po1SQdv3p8eF/bRngBUmtvnwHW2sz0Af2jPnsBtmjxfQI6nHUIpa+CjoA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/HVUFstuBuhIWqX4iReEsDxsRdRA>
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:51:16 -0000

Hi,

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

That was my impression too. In other words - make it possible to handle
such extremely long keys in probably suboptimal way, but with minimal
possible changes to the protocol. So that those who need them could use them,
but no promises that protocol will optimized for them.

Regards,
Valery.

> > Panos
> 
> Cheers Tobias