Re: [Cfrg] Postquantum cryptography in IETF protocols

"Tams, Benjamin" <Benjamin.Tams@secunet.com> Wed, 15 March 2017 13:12 UTC

Return-Path: <Benjamin.Tams@secunet.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52983131493 for <cfrg@ietfa.amsl.com>; Wed, 15 Mar 2017 06:12:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 daun_3SfOrf9 for <cfrg@ietfa.amsl.com>; Wed, 15 Mar 2017 06:12:34 -0700 (PDT)
Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D5E1314A2 for <cfrg@irtf.org>; Wed, 15 Mar 2017 06:12:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 7C4B820E79; Wed, 15 Mar 2017 14:12:30 +0100 (CET)
X-Virus-Scanned: by secunet
Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkl7nfjcoVRM; Wed, 15 Mar 2017 14:12:19 +0100 (CET)
Received: from mail-essen-02.secunet.de (mail-essen-02.secunet.de [10.53.40.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id A4EEC20E84; Wed, 15 Mar 2017 14:10:59 +0100 (CET)
Received: from MAIL-ESSEN-01.secunet.de ([fe80::1c79:38b7:821e:46b4]) by mail-essen-02.secunet.de ([fe80::4431:e661:14d0:41ce%16]) with mapi id 14.03.0319.002; Wed, 15 Mar 2017 14:10:59 +0100
From: "Tams, Benjamin" <Benjamin.Tams@secunet.com>
To: Watson Ladd <watsonbladd@gmail.com>
CC: "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] Postquantum cryptography in IETF protocols
Thread-Index: AQHSnTVAjC974e0YRUO7yMHUwccYLqGV1MdA
Date: Wed, 15 Mar 2017 13:10:58 +0000
Message-ID: <78B0B91A8FEB2E43B20BCCE1326131812D6B6CC3@mail-essen-01.secunet.de>
References: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> <CACsn0cmaE=W=s-uHL3tHFa6zXFnK8OA1BYHYtr5q21VtxxY8Sg@mail.gmail.com>
In-Reply-To: <CACsn0cmaE=W=s-uHL3tHFa6zXFnK8OA1BYHYtr5q21VtxxY8Sg@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.36.126.244]
x-exclaimer-md-config: 2c86f778-e09b-4440-8b15-867914633a10
x-g-data-mailsecurity-for-exchange-state: 0
x-g-data-mailsecurity-for-exchange-error: 0
x-g-data-mailsecurity-for-exchange-sender: 23
x-g-data-mailsecurity-for-exchange-server: cbe3d3f7-b9e3-4256-b890-f24c4306a01c
x-g-data-mailsecurity-for-exchange-guid: 46F1370E-EA29-42F3-BEBF-FFB0C0A3C23A
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/4PaI8fmNLoTWNB5kYr05KYziIW0>
Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Mar 2017 13:12:35 -0000

Hi Watson,

> Why should we preempt the current NIST postquantum standardization efforts?

According to the timeline suggested in 

http://csrc.nist.gov/groups/ST/post-quantum-crypto/workshops.html

first NIST standardization drafts  for postquantum key exchange algorithms will appear in 2023 - 2025. For the use cases that need long-term confidentiality of approx. 15 years (as mentioned in John's post) we should not wait 6-8 years before we can even start with implementing PQ-safe key exchange algorithms for these purposes.

I appreciate the efforts of NIST because the specification outputs will have passed a 3-5 year analysis phase and can then be considered more robust as post-quantum key exchange algorithms that we have today; and, maybe any specification that we can establish now, will eventually turn out to be vulnerable. On the other hand, if we implement a hybrid key exchange algorithm suitable for implementation, as in

https://tools.ietf.org/html/draft-whyte-qsh-tls13-03

we will not lose security but gain the possibility of having PQ-safety already in the near future. Furthermore, the draft already refers to four PQ-safe algorithms but only to one specific - NTRU.  Why not specify the remaining by CFRG? Not for recommending them as a final specification but for temporary using them in applications where PQ-safety is required already now.

Kind regards,
Benjamin