Re: [Cfrg] Postquantum cryptography in IETF protocols

William Whyte <wwhyte@onboardsecurity.com> Wed, 15 March 2017 17:28 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 59ED3131743 for <cfrg@ietfa.amsl.com>; Wed, 15 Mar 2017 10:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ykoVCS-qbZVQ for <cfrg@ietfa.amsl.com>; Wed, 15 Mar 2017 10:28:54 -0700 (PDT)
Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 D2A1113174E for <cfrg@irtf.org>; Wed, 15 Mar 2017 10:28:39 -0700 (PDT)
Received: by mail-wr0-x231.google.com with SMTP id u108so15734838wrb.3 for <cfrg@irtf.org>; Wed, 15 Mar 2017 10:28:39 -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=E1iHjkD5ZC1o/lTTCjDf2khEVPcNVn8+PxiBdg4PFRI=; b=CLERl4O+r5CvF0i/NA6SljX7woxshwwOGah/Dlw1t5iUiC7ErJD33tok0e0RmbWy9Y WzBOVdgjH6+y0T+2JQfjD7hXzv5x8D/aCttcRBnZKNsmRFCIuri3k9s+JtPVvlevKtJT lBpXwPlFoVArA4KzuYGtc67NyBmmyTSw49ijU=
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=E1iHjkD5ZC1o/lTTCjDf2khEVPcNVn8+PxiBdg4PFRI=; b=mLv4xh9js+uDBq0jfwZ4oa7+Dw3dcaYTQhBOT/BWonhtUTJ2/rDdvQ/gacrM/qE4xW +e4j1UxUuKUSIVZJnJEygnS9360sYcxv0tXdHFv7NdYvJGYoG8JIKRBx0fbATOgI0nz/ lFm6N79z8+Y6SQdcUHcV3MdPJY86xnRDxYZSdzVzWDpxzOeYr7dl/sch6XLJM9vPYoij hL16ycpd3x+1VQLJEhGK1/X4QRDdS7XQH3tRjGq3vyPm9wt9miKv+VzS0NbqanqTIKhC xqZWGM/BXfXA3XDUuLe5gSK7KUYFNS+nL7so1Ob57ygw/8SC8xiRYtr++1CM79OCVtpU UH7g==
X-Gm-Message-State: AFeK/H1OVSoOOI5Ff3OcLnXvulR30j4GI3ov1lVXhVEl0mlyGZMttN8G8akFF6lPfgxGBysxtLvmMtmv1bHHQw==
X-Received: by 10.223.171.78 with SMTP id r14mr3852109wrc.113.1489598918242; Wed, 15 Mar 2017 10:28:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.166.5 with HTTP; Wed, 15 Mar 2017 10:28:17 -0700 (PDT)
In-Reply-To: <D4EF2F08.5AEC3%john.mattsson@ericsson.com>
References: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> <CACsn0cmaE=W=s-uHL3tHFa6zXFnK8OA1BYHYtr5q21VtxxY8Sg@mail.gmail.com> <78B0B91A8FEB2E43B20BCCE1326131812D6B6CC3@mail-essen-01.secunet.de> <20170315152426.GA22135@LK-Perkele-V2.elisa-laajakaista.fi> <D4EF2F08.5AEC3%john.mattsson@ericsson.com>
From: William Whyte <wwhyte@onboardsecurity.com>
Date: Wed, 15 Mar 2017 13:28:17 -0400
Message-ID: <CAND9ES1OT1j2x7g023GKGpo6ZgTz1FXQe7=Cc8PNiVdik-93ZA@mail.gmail.com>
To: John Mattsson <john.mattsson@ericsson.com>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, "Tams, Benjamin" <Benjamin.Tams@secunet.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary=94eb2c1b40ac61521a054ac8467d
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/WgfhQ82kKSy2Ay30d1Ucu7WKQh8>
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 17:28:57 -0000

That draft is in the process of being updated, but it was never intended to
propose static NTRU keys; if it looks like it does, it needs to be
clarified. NTRU key generation is fast enough that there's no need to avoid
ephemeral keys.

Cheers,

William

On Wed, Mar 15, 2017 at 1:08 PM, John Mattsson <john.mattsson@ericsson.com>
wrote:

> TLS 1.3 forbids static RSA for a reason, draft-whyte-qsh-tls13-03 seems to
> bring it back in the form of static NTRUEncrypt. I see no reason to do
> that. If someone wants to do early PCQ in TLS 1.3, I think the two lattice
> based protocols suggested by David McGrew (Frodo, New Hope) as well as
> Supersingular Elliptic Curve Igogeny Diffie-Hellman (SIDH) is the way to
> go. The lattice-based variants are fast while SIDH has much smaller
> ephemeral keys.
>
> John
>
>
>
> On 2017-03-15, 16:24, "Cfrg on behalf of Ilari Liusvaara"
> <cfrg-bounces@irtf.org on behalf of ilariliusvaara@welho.com> wrote:
>
> >On Wed, Mar 15, 2017 at 01:10:58PM +0000, Tams, Benjamin wrote:
> >> Hi Watson,
> >>
> >> > Why should we preempt the current NIST postquantum standardization
> >>efforts?
> >>
> >> https://tools.ietf.org/html/draft-whyte-qsh-tls13-03
> >
> >Briefly read that document. Some quick comments:
> >
> >- Looks quite confusing. Especially the parts about HelloRetryRequest.
> >  But looking closer, that message is not used except for handling
> >  missed algorithm guess, right? So that if client guesses right (and
> >  it can make multiple guesses at cost of computation and bandwidth)
> >  there might not be HRR, right?
> >- I don't think extending TLS extensions past 64kB is feasible.
> >  Especially in ClientHello It would require changes with nasty
> >  side-effects.
> >- The document looks to be made for older draft of TLS 1.3. The
> >  way key is combined is bit unclear. I presume the key mixing
> >  should be done in two steps (adding a new step into TLS 1.3
> >  key schedule, as the two existing mixing steps are already
> >  used for PSK and DH) because that's likely the easiest to
> >  implement.
> >- Adding new handshake messages should be avoided, but AFAICT,
> >  there are none added.
> >
> >
> >-Ilari
> >
> >_______________________________________________
> >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
>