Re: [Cfrg] Postquantum cryptography in IETF protocols

William Whyte <wwhyte@onboardsecurity.com> Wed, 22 March 2017 12:34 UTC

Return-Path: <wwhyte@onboardsecurity.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 7E5B1129739 for <cfrg@ietfa.amsl.com>; Wed, 22 Mar 2017 05:34:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.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 djfIifPLV46U for <cfrg@ietfa.amsl.com>; Wed, 22 Mar 2017 05:34:47 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 63A5A129722 for <cfrg@irtf.org>; Wed, 22 Mar 2017 05:34:47 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id n11so35306566wma.1 for <cfrg@irtf.org>; Wed, 22 Mar 2017 05:34:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l7X8JgQtZtjSoJaSWTEdK+QtWnJxK3zjJbCf1QwVWVE=; b=NSH6cQ2yKQYauokezvC2AjoiSU6TGD8DwYgDxiXuHKqePX9dWRL6CtBFjpZAW/Jh93 YaDN/k71GvvmS5Q2FXWc6hRkIk0O+thD3I6EUZVkdhYyQ3FqiMAeMBt3gJm+KR3l4bWy /PUQ2ZSWLL77HMm4Ipy2DHh9WPYXKZ9qtCDEM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l7X8JgQtZtjSoJaSWTEdK+QtWnJxK3zjJbCf1QwVWVE=; b=X54vtb94qxgrEJ1VGPBUTvObpGI5x8DWbbKJnx2P/KC5lWXVBrVD1fFb99Ats06gW6 h9SXmTxnilFafj/PnjP9n+N8M37R7+uzBFEzfg0+ahQ+ZfGsaHelavhL+WJcntk1vses 4UgZQfVp7CMgMAXOISFAz/5t8IALiwRX1mHI3jQ+O8Up3jA0PE0PTbg/Hyl7zSeNfgZL MVSs27wO7Gc065/+igvgLE5uiChsjqZd2KZMrr7M3BsqFw6kaRJtj19O4C5RnWcdg40j oXP/UG1RfLXU+f+Iy6w77RQATyjzTR0WH3CkreE2zMh5sXyPhIsIWUSdL1E59hSnBSRl T4RA==
X-Gm-Message-State: AFeK/H3mbGNcFYPnB1wxiv2HFzjvgCkVDMEfZyQa7m07bSSkFZv76YNfokpKROrisT9Iazxzav3c3cX5tUmwvg==
X-Received: by 10.28.30.19 with SMTP id e19mr7436377wme.52.1490186085803; Wed, 22 Mar 2017 05:34:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.166.5 with HTTP; Wed, 22 Mar 2017 05:34:25 -0700 (PDT)
In-Reply-To: <D4F81DF8.8CC46%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>
From: William Whyte <wwhyte@onboardsecurity.com>
Date: Wed, 22 Mar 2017 08:34:25 -0400
Message-ID: <CAND9ES2QC2Bv4oZhsH9--2TFCoW5mMVbWogAbS30igvP0SeBgQ@mail.gmail.com>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
Cc: Watson Ladd <watsonbladd@gmail.com>, "Tams, Benjamin" <Benjamin.Tams@secunet.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary=001a114b3c824b478b054b50fc5a
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/rOOzQMQv1SkVtNFqvr8-96q1UKg>
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 12:34:51 -0000

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