IETF Logo Mail Archive

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

Cen Jung Tjhai <CJT@post-quantum.com> Fri, 29 September 2017 15:37 UTC

Return-Path: <CJT@post-quantum.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 533421330B0 for <ipsec@ietfa.amsl.com>; Fri, 29 Sep 2017 08:37:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 CWQVSw0I0vtj for <ipsec@ietfa.amsl.com>; Fri, 29 Sep 2017 08:37:38 -0700 (PDT)
Received: from relay.ezis.com (relay.ezis.com [5.153.73.19]) by ietfa.amsl.com (Postfix) with ESMTP id 64932133063 for <ipsec@ietf.org>; Fri, 29 Sep 2017 08:37:38 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.42,453,1500937200"; d="scan'208";a="2493890"
Received: from unknown (HELO pqex01.post-quantum.com) ([192.168.142.3]) by ironport.ezis.com with ESMTP; 29 Sep 2017 16:37:38 +0100
Received: from PQEX02.post-quantum.com (192.168.142.18) by PQEX01.post-quantum.com (192.168.142.3) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 29 Sep 2017 16:37:40 +0100
Received: from PQEX02.post-quantum.com ([fe80::f470:9812:e4eb:5bd3]) by PQEX02.post-quantum.com ([fe80::f470:9812:e4eb:5bd3%13]) with mapi id 15.00.1320.000; Fri, 29 Sep 2017 16:37:39 +0100
From: Cen Jung Tjhai <CJT@post-quantum.com>
To: Valery Smyslov <svanru@gmail.com>, Paul Wouters <paul@nohats.ca>
CC: "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: [IPsec] Proposed method to achieve quantum resistant IKEv2
Thread-Index: AQHTDE+mPH5PNqQgTkK9LOvm4SvL2qJ0GbUAgAIwNdWABXuFgIAAg/cAgE0k7ICAAVMcAIABWnMAgAAifICAAAWPgIAABHAA
Date: Fri, 29 Sep 2017 15:37:39 +0000
Message-ID: <F85173BF-93A4-4E19-B5C7-99F840FC4421@post-quantum.com>
References: <BBEB2C9C-9B96-4C6C-BB9B-4415F096FAE1@cisco.com> <041b01d30d21$8d33f230$a79bd690$@gmail.com> <1501968567726.89885@post-quantum.com> <22922.57101.227283.113155@fireball.acr.fi> <7769.1502301632@obiwan.sandelman.ca> <04B7D970-30B0-4AE8-BAF9-210746B56FFF@cisco.com> <14600.1506615504@obiwan.sandelman.ca> <00bd01d33922$a487c970$ed975c50$@gmail.com> <alpine.LRH.2.21.1709291052330.24648@bofh.nohats.ca> <00d001d33936$a8948800$f9bd9800$@gmail.com>
In-Reply-To: <00d001d33936$a8948800$f9bd9800$@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3124)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.3.255.7]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D1ECC4BE8C7D5F4190728E89037C9CEF@post-quantum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/wCovL5V652aUPAfIcSQoMLNtAtQ>
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: Fri, 29 Sep 2017 15:37:40 -0000

Hi Paul and Valery,

>> Either a new exchange or an untrusted stream of
>> fragments. Either way, a lot of complexity for a rather moving target
>> goal that we don't understand yet. I'd personally rather wait until we
>> know a bit more about the direction that quantum safe protocols are
>> really going to.
> 
> Fully agree. And the size of the quantum safe KE payload is really important for IKE.
> When I hear that it could be several MB, it makes me nervous - it seems
> that transferring so much unauthenticated data will become a good target for DoS attacks.
> Several KB is a bit better, at least it seems that we can deal with this amount.

There is a type of PQ key-exchange primitive (the oldest one) whose public key is around 1MB. Whether or not this primitive needs to be considered, we can wait until we have more information. However, for the rest of known PQ the primitives (except one) so far, their public key size is still larger than 1KB. So fragmentation may still occur for nodes whose MTU is set to around 1KB.

Best regards,
CJ

v2.23.0 | Report a Bug | By Email