Re: [TLS] Hybrid key exchange in TLS 1.3 and variable-length secrets

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 16 September 2020 17:28 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278D23A0FBA for <tls@ietfa.amsl.com>; Wed, 16 Sep 2020 10:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 eX_m9IvD18CD for <tls@ietfa.amsl.com>; Wed, 16 Sep 2020 10:28:51 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2b.welho.com [83.102.41.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BB2B3A0FB4 for <tls@ietf.org>; Wed, 16 Sep 2020 10:28:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 1F88CD0169 for <tls@ietf.org>; Wed, 16 Sep 2020 20:28:49 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 95qNzrdyeowe for <tls@ietf.org>; Wed, 16 Sep 2020 20:28:48 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-140-94.rev.dnainternet.fi [87.92.140.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id D8F2B7A for <tls@ietf.org>; Wed, 16 Sep 2020 20:28:47 +0300 (EEST)
Date: Wed, 16 Sep 2020 20:28:46 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20200916172846.GA1726088@LK-Perkele-VII>
References: <CABiKAoSGpodvQAegOhDxKxvDWoUsZBZL2JFWbtyseH+19cj6VQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABiKAoSGpodvQAegOhDxKxvDWoUsZBZL2JFWbtyseH+19cj6VQ@mail.gmail.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2GCUM6AU_FDuUfHYv2mXvD6I_sA>
Subject: Re: [TLS] Hybrid key exchange in TLS 1.3 and variable-length secrets
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Sep 2020 17:28:53 -0000

On Wed, Sep 16, 2020 at 07:26:56PM +0300, Nimrod Aviram wrote:
> 
> We also note that a related RFC exists, "Hybrid Post-Quantum Key
> Encapsulation Methods (PQ KEM) for Transport Layer Security 1.2"
> [4]. However, that RFC apparently only uses BIKE, Kyber or SIKE as the
> PQ KEM. To our knowledge, all three KEMs have fixed-length secrets. It
> may be prudent to add cautionary language to that document as well,
> in case other KEMs are used in the future.

Searching for newest available versions of finalists/alternates
specifications, all have constant output lengths except Kyber (usually
32 octets, but HQC uses 64, and FrodoKEM and SIKE use 16 at Cat1 and 24
at Cat3).

Kyber is a bit odd case. The spec uses raw XOF output as key, and the
specification does not seem to say anywhere how long the output should
be. The reference implementation always uses 32 octets as output
length.

So none of the finalists/alternates need variable-length secret fields.
And with TLS 1.3, due to the way secret is injected into key schedule,
a length field would only be strictly needed for injectivity if there
are multiple variable-length subkeys.

And with regards to TLS 1.2, I would just leave it. Adding PQC to TLS
1.2 is harder than adding PQC to TLS 1.3 (this is definitely not one
of those "old versions for free" cases), and TLS 1.2 is pretty much
obsolete anyway.


-Ilari