Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

"Martin Thomson" <mt@lowentropy.net> Wed, 31 July 2019 00:31 UTC

Return-Path: <mt@lowentropy.net>
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 90D2312011B for <tls@ietfa.amsl.com>; Tue, 30 Jul 2019 17:31:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Hn+bB7IA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=M/ssZSXw
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 H3mfdicmbYF0 for <tls@ietfa.amsl.com>; Tue, 30 Jul 2019 17:31:48 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC5F512008B for <tls@ietf.org>; Tue, 30 Jul 2019 17:31:47 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 2F7DE569 for <tls@ietf.org>; Tue, 30 Jul 2019 20:31:47 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 30 Jul 2019 20:31:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=ipMojqy3iyGFqpzKf6cT+eeRJqjWJr4 2oSobUs594ks=; b=Hn+bB7IAeAfyek7zTodkTx1HNirqvqokRvOLiyEEpNleeFh JVTbrLfo7k0wAI+6DhnFNnbVXRYgcObp5SEuWnDumpHkCZWA5yeRw57sFSev/ySC eBD3dqGyiWIJsSRyofOudNChcoR0OSewVyM0UaGOUl7fkHGEFhrCtztTBwI9yFJA 4nqIKVrxZvbflbWA8zeRolK4KAIa1Zb1oaL97MDnFcCnE8IsAIixLevc9hLDnAQy NZnxUmd7NyBNu7lstNna1IDnSa2bDzMPe37/FZwlOGmti/8VrP6OlcNjnfMCMpJr dqhWwSWTjM4fJ/aphUaRX2fJrvLlnemuuGeo96g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=ipMojq y3iyGFqpzKf6cT+eeRJqjWJr42oSobUs594ks=; b=M/ssZSXwGWH3TEodWi31lz z83VehYGWWroF4JNHu0HLUgHq2m4qkb5KFIe0EnzlURwHol6bvCTvVrcsqmFsuX5 VTYvm+B4sBa301r/0kHnCKWwkGTeDxrhPqRrlvuPrT4GhHaNd5/EV9t+BH9LPo2u ORwQV+IWR+V9wt7qQI6heLyd0dkTrcVMRPHUo1X1l/utDZzltxvT5ueYREuapEst +e5mOusMUicjaUsZaJNOeFX2B+O83itKK5+5gKKiADprXI6HjPuEOxnnH/hwkKm3 IX9w0xB+VbLzJ3RvOnxhM+cSXNu0z9PMW5FghouOSPppxofiSNS0izqUMQ9id8+Q ==
X-ME-Sender: <xms:cuFAXQ5j2ccXEyignoDRHLJOeUfI7XCFNLVtfrM69l7LfmH093AhKA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrleeggdefiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:cuFAXSU5iPqOP44s8TTGmxuHickaN6nuyDbiUWVTCpghHTT1sNdc-A> <xmx:cuFAXQ4p1n_7m6fSO82WlrP_hE93KI2WIua3-Wt6pnhIMa0YToggOg> <xmx:cuFAXVI2pQDJgJdJw1u2cC0Up61pk7UsIhBr7gTI8RbAum6G8Bbuqw> <xmx:cuFAXf1vvxEZCitMjXLSjb8kUw9nJW4H_Z9SM4E5AJfaPkn8oVTaog>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 445FFE00A7; Tue, 30 Jul 2019 20:31:46 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-799-g925e343-fmstable-20190729v1
Mime-Version: 1.0
Message-Id: <681b10d7-f404-4573-a60f-22d9239ccb0c@www.fastmail.com>
In-Reply-To: <20190730202023.GB21846@akamai.com>
References: <MN2PR11MB38719A31081434FEF6A84999C1DC0@MN2PR11MB3871.namprd11.prod.outlook.com> <CACsn0c=bmsyDPhTUtCcEv1WnnsR8OmDO67TFTu1aWSxikESOEA@mail.gmail.com> <CAF8qwaAcjC0+4A1ySWu3w6CiY0iA+AVytOO=aSt5BgwBfKiYvw@mail.gmail.com> <DM5PR2101MB09177EFFFB5C2D64556724848CDC0@DM5PR2101MB0917.namprd21.prod.outlook.com> <MN2PR11MB387187D8FEEF1A16DD8483BAC1DC0@MN2PR11MB3871.namprd11.prod.outlook.com> <20190730202023.GB21846@akamai.com>
Date: Wed, 31 Jul 2019 10:31:47 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/jtlNzTtqxl58OWRDV7K6bllfrI4>
Subject: Re: [TLS] =?utf-8?q?Options_for_negotiating_hybrid_key_exchanges_for?= =?utf-8?q?_postquantum?=
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, 31 Jul 2019 00:31:50 -0000

On Wed, Jul 31, 2019, at 06:21, Benjamin Kaduk wrote:
> It's clear that anything we do needs to preserve compat with all four
> possibilities in the interop matrix for (old, enhanced) (client,
> server).  Your closing note about duplicating payloads is something of a
> different creature, though, and perhaps should be considered more
> explicitly.

Adam directly addressed that concern at the meeting; and others agreed.  25519 shares are small enough that worrying about duplication isn't necessary.  The delta is tiny when considering the need to additionally signal combinatorics in the scheme imagined by Option 1.

So I'd like to add my voice to those in support of buttoning down a single scheme (i.e., Option 2).  The cost of the added indirection is significant.  I'll take the addition of a few bytes to the ClientHello over that any time.

The other arguments all assume that we'll fail to narrow the parameter set or number of options.  My view is that deciding on a single parameter set is not just desirable, but necessary.  My experience suggests that clients won't want to expend the resources necessary to create and send two PQ shares.  No PQ scheme that I've seen are close enough in terms of efficiency - bytes or CPU - to allow for multiple shares to be offered.

Option 2 also allows us to defer the combination method.  While I imagine that concatenation will be injective for most schemes, which might be sufficient, we might want to change the combination method as we learn more.  Option 2 allows us to include a definition for how secrets produced by each scheme are merged into the key schedule for each combination.