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

Benjamin Kaduk <bkaduk@akamai.com> Tue, 30 July 2019 20:20 UTC

Return-Path: <bkaduk@akamai.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 5C9CF12022A for <tls@ietfa.amsl.com>; Tue, 30 Jul 2019 13:20:41 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 GTnHphNQEavq for <tls@ietfa.amsl.com>; Tue, 30 Jul 2019 13:20:40 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC1D12026D for <tls@ietf.org>; Tue, 30 Jul 2019 13:20:39 -0700 (PDT)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x6UKHOPX031609; Tue, 30 Jul 2019 21:20:33 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=jan2016.eng; bh=E+KfUowO/1Dm1aE0LFEAiKUotROKBFmGozqAQ46S5jY=; b=WN7W9MI9kAP5TJKUUoiil/s+GLgTSrMnFzKOzf9FC6vagp+oBtG/eCQbZ5Dv5HFJmjFb APFmgJ+m7/qvLn38AQ4Bx0T6PqX8imDOUNZqPfgAIbO6Or9ZMc2FCItU+ByE2kiW5vxE vgaNXwBf2J15iqxt9ltGrl5AELswr0mLIenA0fjUGYCQ+HR8Bg+6xa2eEGiO2BsXUytb qIyjwqIsWNQoXihGASIWHNTHvn0X3NuSs7x6Uy0po8erEkg2npGUGP9UR9YDyJSx83RB izwdzptaMqK2cDt5jkXt4/59HabkAjWW8c07GEKVYKgYnnxp7u6j44ovx2zw25f0dblT 5w==
Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2u0dv65tq2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jul 2019 21:20:33 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x6UKHnVV010795; Tue, 30 Jul 2019 16:20:32 -0400
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2u0hy0f836-1; Tue, 30 Jul 2019 16:20:31 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 5766181422; Tue, 30 Jul 2019 20:20:26 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1hsYbg-0008KQ-FU; Tue, 30 Jul 2019 15:20:24 -0500
Date: Tue, 30 Jul 2019 15:20:24 -0500
From: Benjamin Kaduk <bkaduk@akamai.com>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
Cc: Andrei Popov <Andrei.Popov=40microsoft.com@dmarc.ietf.org>, David Benjamin <davidben@chromium.org>, Watson Ladd <watsonbladd@gmail.com>, TLS List <tls@ietf.org>
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <MN2PR11MB387187D8FEEF1A16DD8483BAC1DC0@MN2PR11MB3871.namprd11.prod.outlook.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-30_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907300206
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-07-30_10:2019-07-29,2019-07-30 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 suspectscore=0 bulkscore=0 mlxlogscore=999 malwarescore=0 adultscore=0 priorityscore=1501 spamscore=0 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1907300206
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2Ettcvj4z8qfrQN9fVrPJZa7c-w>
Subject: Re: [TLS] Options for negotiating hybrid key exchanges for 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: Tue, 30 Jul 2019 20:20:47 -0000

On Tue, Jul 30, 2019 at 07:44:13PM +0000, Scott Fluhrer (sfluhrer) wrote:
> I believe that one important property (of either of the options I listed) is a nice fallback if an enhanced client talks to an older server.  In both cases, the server will see a series of named groups that it doesn’t know (which it will ignore), and possibility an extension it doesn’t know (which it will ignore); the server will accept either a named group that it does understand (if the client did propose a traditional group as a fall back), or it will come to the correct conclusion that the two sides have no mutually acceptable security policy.
> 
> It is not clear if the proposal you outlined share this property; do you duplicate a payload that an unenhanced server would assume only occurs once?

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.

Trying to uplevel a bit, option 1 is essentially introducing another
layer of indirection, with the need to carry the additional lookup table
on the side.  This has the disadvantages of both needing the extra layer
of indirection and also can have unfortunate impact from needing the
extra table on the side in more places than is immediately obvious
(i.e., the ESNI case that David mentioned).  The perceived benefit is
that we allocate fewer codepoints, avoid duplicating some KeyShare
information, and maybe get increased flexibility about how we combine
schemes.  In contrast, option 2 is more smoothly integrated into the
existing negotiation mechanism, but has the potential costs of allocating
more codepoints and duplicating some KeyShare information.

But, what are the KeyShare bits that will get duplicated?  If we're just
doing "X25519 plus one post-quantum", only the X25519 share gets
duplicated, even if we want to do several different post-quantum options
in "X25519 plus one post-quantum" form.  And X25519 shares are pretty
small, all things considered!  I'd find the concern about duplicated
KeyShares more compelling if we think we're going to end up needing to
negotiate between (X25519 plus PQ1 plus PQ2) and (X25519 plus PQ2 plus
PQ3) and (X25519 plus PQ1 plus PQ2 plus PQ3), where the PS shares add up
fast.  It's not clear that the ecosystem will end up in a place where we
need to do the latter.

-Ben