Re: [Cfrg] Postquantum cryptography in IETF protocols

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Wed, 22 March 2017 14:36 UTC

Return-Path: <Kenny.Paterson@rhul.ac.uk>
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 60B18131741 for <cfrg@ietfa.amsl.com>; Wed, 22 Mar 2017 07:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level:
X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.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 V5UcgRCxkcLT for <cfrg@ietfa.amsl.com>; Wed, 22 Mar 2017 07:36:37 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0077.outbound.protection.outlook.com [104.47.2.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3147E131746 for <cfrg@irtf.org>; Wed, 22 Mar 2017 07:36:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=au6ojWBNjQnjugRb5F+t5tqrjt5tKTM/t+2V5cNjbWY=; b=2iW1+cA2edyvOmaXSJC4H7lbIscgg80Kr/4Dn62Ol4rRbIy5imLH9XptaCiFeEIdP103sNaP7ZqJkGDEHfxLyVtVBjU0UDUZ5fEGbUvJ+gZk4w749VOGJuY6rw/V6uiHrnctXNQ08lDr/718QtqTl9tRb2s+gVqPmQ95tRkI2r4=
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Wed, 22 Mar 2017 14:36:05 +0000
Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([10.168.2.156]) with mapi id 15.01.0977.019; Wed, 22 Mar 2017 14:36:04 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: William Whyte <wwhyte@onboardsecurity.com>
CC: Watson Ladd <watsonbladd@gmail.com>, "Tams, Benjamin" <Benjamin.Tams@secunet.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] Postquantum cryptography in IETF protocols
Thread-Index: AQHSnTVJcjR350Po60+E6F5IvEbv/KGVkP8AgAtEM4CAAAGqgIAAIo8A
Date: Wed, 22 Mar 2017 14:36:04 +0000
Message-ID: <D4F839CB.8CC7E%kenny.paterson@rhul.ac.uk>
References: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> <CACsn0cmaE=W=s-uHL3tHFa6zXFnK8OA1BYHYtr5q21VtxxY8Sg@mail.gmail.com> <D4EEA9B7.8BF7D%kenny.paterson@rhul.ac.uk> <D4F81DF8.8CC46%kenny.paterson@rhul.ac.uk> <CAND9ES2QC2Bv4oZhsH9--2TFCoW5mMVbWogAbS30igvP0SeBgQ@mail.gmail.com>
In-Reply-To: <CAND9ES2QC2Bv4oZhsH9--2TFCoW5mMVbWogAbS30igvP0SeBgQ@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.1.161129
authentication-results: onboardsecurity.com; dkim=none (message not signed) header.d=none;onboardsecurity.com; dmarc=none action=none header.from=rhul.ac.uk;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [134.219.227.30]
x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1906; 7:lHjqncQuoIvvvUVyrEFUYy0fJSdBistw5Q6egkX8MKkatGfX+GaxQu06Pd1YPmga+4t0QUoKyIqeDIGOVir9pv2dZiqrolxQO+xPkk5kPgowG9Xuwh7AsTO8i9qNm4FnquGpKvA3cfSXpXQTdkTDduaJoo/ee+UJsfzYqa5/mHdCNYiDavh0YGqleX3tgy4JgwAG31y1mhlv4MKykEHLm7qCPFNhP6GwozsvbIdfRNCw9pna2BUsmwqV19UDecuk6NfZvD5MWQTXB4Z7VnXysysa7RmD2dTsnZHMAWXmGL3ESqsTNVG0R0yVApUiU6F6lbUTPLbcsoVd3liVDiFznw==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(52314003)(24454002)(377454003)(2906002)(3846002)(8936002)(305945005)(50986999)(54906002)(2950100002)(6916009)(39060400002)(42882006)(4001350100001)(99286003)(6436002)(38730400002)(6512007)(83506001)(74482002)(53936002)(6306002)(110136004)(53546009)(54356999)(6486002)(229853002)(102836003)(122556002)(6246003)(561944003)(6506006)(189998001)(3660700001)(36756003)(86362001)(66066001)(4326008)(2900100001)(7736002)(77096006)(76176999)(3280700002)(81166006)(8676002)(5660300001)(93886004)(25786009)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1906; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
x-ms-office365-filtering-correlation-id: 3e58d3c0-cb85-4257-e71d-08d47130c52b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:AM4PR0301MB1906;
x-microsoft-antispam-prvs: <AM4PR0301MB190681790D9504A22C96B676BC3C0@AM4PR0301MB1906.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(166708455590820)(266576461109395);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(20161123558025)(6072148); SRVR:AM4PR0301MB1906; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1906;
x-forefront-prvs: 02543CD7CD
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <C3C613EFAC194042B3E5B563B4EE1BD7@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2017 14:36:04.5009 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1906
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/bDZ60EIjb8UcZbqjRhE9kkt_5qQ>
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, 22 Mar 2017 14:36:43 -0000

Hi William,

You are right that there's no formally agreed approach for CFRG, but the
current approach that the *leadership* of CFRG (i.e. the co-chairs) would
like to take is that explained in my message below. But we can of course
revisit the question as a research group.

To reiterate: I would consider it a mistake for CFRG to go down the route
of standardising PQ algorithms ahead of the NIST process, aside from in
mature areas like hash-based signatures where we have a lot of research
that we can draw on. For me, the rest of the field is in too much of a
state of flux, and the expertise that might otherwise be available is
(rightly) focussed on the NIST process with its (rightly) much longer
timescales. 

I would welcome a CFRG-wide decision to look at "an interoperability
specification for PQ algorithms to be used in a hybrid context" as you put
it. But that's not the same as looking at PQ algorithms. Let's not
conflate/confuse them.

Further comments/discussion very welcome - as always.

Cheers,

Kenny 


On 22/03/2017 12:34, "William Whyte" <wwhyte@onboardsecurity.com> wrote:

>Hi Kenny,
>
>
>I didn't see that mail, thanks for forwarding.
>
>
>Personally I find Ben's position more convincing:
>
>
>>> The other way round does neither: Just because there are Internet
>>>Drafts specifying
>PQ-safe key exchange algorithms, this does not mean they have to be
>implemented. Anyway,
>existing implementations are indications for the need of PQ-safe key
>exchange algorithms.
>Therefore, in my view, it is reasonable to specify Internet Drafts for
>state-of-the-art
>PQ-safe key exchange algorithms suitable for implementation.
>
>There are organizations that need to plan for a migration now in order to
>properly manage risk and that can't wait for the NIST process to
>complete. Providing an interoperability specification for PQ algorithms
>to be used
> in a hybrid context allows these organizations to start development and
>prototype deployment.
>
>
>I'm not sure the "current CFRG approach" has been formally decided on;
>it's more "what CFRG happens to be doing at the moment". If CFRG members
>see value in specifying a wider range of algorithms, the CFRG approach
>can be
> changed.
>
>
>Cheers,
>
>
>William
>
>
>
>
>
>
>
>
>On Wed, Mar 22, 2017 at 8:26 AM, Paterson, Kenny
><Kenny.Paterson@rhul.ac.uk> wrote:
>
>Hi,
>
>This e-mail I sent back on 15th March laying out the CFRG leadership's
>current position on post-quantum algorithms does not appear to have made
>it into the CFRG archive and perhaps did not make it to the list. It seem
>pertinent to send it again, in view of an on-going discussion on the list.
>
>Regards
>
>Kenny
>
>On 15/03/2017 08:23, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> wrote:
>
>>Hi Benjamin,
>>
>>Full disclosure: I am involved in one proposal being prepared for the
>>NIST
>>process.
>>
>>
>>Wearing my CFRG co-chair's hat, I would say that Watson is correct, in
>>the
>>sense that the current CFRG approach is to define RFCs for a few
>>relatively mature post-quantum primitives, such as hash-based signatures,
>>but to wait for the results of the NIST process for everything else.
>>
>>The NIST process is going to run for many years - it just started, and is
>>slated at 5-7 years. It will entail a significant effort by the research
>>community, which is right and proper given the current state of the
>>field.
>>
>>Regards,
>>
>>Kenny
>>
>>On 15/03/2017 02:38, "Cfrg on behalf of Watson Ladd"
>><cfrg-bounces@irtf.org on behalf of
>watsonbladd@gmail.com> wrote:
>>
>>>On Tue, Mar 14, 2017 at 10:31 AM, Tams, Benjamin
>>><Benjamin.Tams@secunet.com> wrote:
>>>> Hi John,
>>>>
>>>>> Good that CFRG starts some more detailed discussion on PQC. It makes
>>>>>sense
>>>>> to support post-quantum key exchange for use cases that need
>>>>>long-term
>>>>> confidentiality (15 years). For other use cases I think it can wait
>>>>>until
>>>>> PQC key exchange algorithms has been thoroughly evaluated and
>>>>> standardized. If implemented now, it should be used in addition to
>>>>>ECDHE,
>>>>> just like Google has done with their experimental New Hope
>>>>>implementation.
>>>>
>>>> I absolutely agree with your view on the subject. Especially for those
>>>>use
>>>> cases where the attack scenario "collect today, decrypt tomorrow" is a
>>>>threat,
>>>> we should start thinking of PQ-safe key exchange methods in time. Even
>>>>if
>>>> they eventually turn out to be insecure; we can now combine them with
>>>> classical key exchange algorithms. We have nothing to lose.
>>>>
>>>> There is already IETF work addressing PQ-security in Internet
>>>>protocols, e.g.
>>>> IKE and an Internet Draft for a Quantum-Safe Hybrid Ciphersuite for
>>>>TLS
>>>>
>>>> 
>https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-03
><https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-03>
>>>> 
>https://tools.ietf.org/html/draft-whyte-qsh-tls13-03
><https://tools.ietf.org/html/draft-whyte-qsh-tls13-03>
>>>>
>>>> On the other hand, there is (to my knowledge) no specification for a
>>>>PQ-safe
>>>> patent-free key exchange algorithm suitable for implementation. In
>>>>fact, in
>>>> 
>https://tools.ietf.org/html/draft-whyte-qsh-tls13-03
><https://tools.ietf.org/html/draft-whyte-qsh-tls13-03>
>>>> only NTRUEncrypt is specified but is subject to patents.
>>>>
>>>> A possible first step is that CFRG creates an Internet Draft. In fact,
>>>> the algorithm New Hope has already been implemented as a plugin for
>>>> strongSwan (IPSec implementation for the Linux kernel)
>>>>
>>>>
>>>>https://github.com/strongswan/strongswan/tree/master/src/libstrongswan/
>>>>p
>>>>l
>>>>ugins/newhope
>>>>
>>>> So why do we not start with a draft for which the above implementation
>>>>can
>>>> serve as a reference implementation?
>>>
>>>Why should we preempt the current NIST postquantum standardization
>>>efforts?
>>>>
>>>> Kind regards,
>>>> Benjamin
>>>>
>>>>
>>>> _______________________________________________
>>>> Cfrg mailing list
>>>> Cfrg@irtf.org
>>>> 
>https://www.irtf.org/mailman/listinfo/cfrg
><https://www.irtf.org/mailman/listinfo/cfrg>
>>>
>>>
>>>
>>>--
>>>"Man is born free, but everywhere he is in chains".
>>>--Rousseau.
>>>
>>>_______________________________________________
>>>Cfrg mailing list
>>>Cfrg@irtf.org
>>>https://www.irtf.org/mailman/listinfo/cfrg
>>
>
>_______________________________________________
>Cfrg mailing list
>Cfrg@irtf.org
>https://www.irtf.org/mailman/listinfo/cfrg
>
>
>
>
>
>
>