Re: [Cfrg] Postquantum cryptography in IETF protocols
Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 15 March 2017 15:24 UTC
Return-Path: <ilariliusvaara@welho.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 67C71131680 for <cfrg@ietfa.amsl.com>; Wed, 15 Mar 2017 08:24:39 -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 FZolbqfuxFPq for <cfrg@ietfa.amsl.com>; Wed, 15 Mar 2017 08:24:37 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id DD6B813167B for <cfrg@irtf.org>; Wed, 15 Mar 2017 08:24:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 13D0F23BCA; Wed, 15 Mar 2017 17:24:35 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 8AutznPUp2Sx; Wed, 15 Mar 2017 17:24:34 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 2F3FA2313; Wed, 15 Mar 2017 17:24:34 +0200 (EET)
Date: Wed, 15 Mar 2017 17:24:26 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "Tams, Benjamin" <Benjamin.Tams@secunet.com>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Message-ID: <20170315152426.GA22135@LK-Perkele-V2.elisa-laajakaista.fi>
References: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de> <CACsn0cmaE=W=s-uHL3tHFa6zXFnK8OA1BYHYtr5q21VtxxY8Sg@mail.gmail.com> <78B0B91A8FEB2E43B20BCCE1326131812D6B6CC3@mail-essen-01.secunet.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <78B0B91A8FEB2E43B20BCCE1326131812D6B6CC3@mail-essen-01.secunet.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/kUro-vkLsL8I7EuOVO_Wp0xjAT0>
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 15:24:39 -0000
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] Postquantum cryptography in IETF protocols John Mattsson
- Re: [Cfrg] Postquantum cryptography in IETF proto… David McGrew (mcgrew)
- Re: [Cfrg] Postquantum cryptography in IETF proto… Tams, Benjamin
- Re: [Cfrg] Postquantum cryptography in IETF proto… William Whyte
- Re: [Cfrg] Postquantum cryptography in IETF proto… Watson Ladd
- Re: [Cfrg] Postquantum cryptography in IETF proto… Tams, Benjamin
- Re: [Cfrg] Postquantum cryptography in IETF proto… Tams, Benjamin
- Re: [Cfrg] Postquantum cryptography in IETF proto… William Whyte
- Re: [Cfrg] Postquantum cryptography in IETF proto… Ilari Liusvaara
- Re: [Cfrg] Postquantum cryptography in IETF proto… William Whyte
- Re: [Cfrg] Postquantum cryptography in IETF proto… John Mattsson
- Re: [Cfrg] Postquantum cryptography in IETF proto… William Whyte
- Re: [Cfrg] Postquantum cryptography in IETF proto… Aaron Zauner
- Re: [Cfrg] Postquantum cryptography in IETF proto… Tams, Benjamin
- Re: [Cfrg] Postquantum cryptography in IETF proto… Paterson, Kenny
- Re: [Cfrg] Postquantum cryptography in IETF proto… William Whyte
- Re: [Cfrg] Postquantum cryptography in IETF proto… Paterson, Kenny