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