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

Watson Ladd <> Tue, 30 July 2019 16:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 836951201C8 for <>; Tue, 30 Jul 2019 09:18:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BaG-nGiGGLGC for <>; Tue, 30 Jul 2019 09:18:12 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4CFB212016F for <>; Tue, 30 Jul 2019 09:18:12 -0700 (PDT)
Received: by with SMTP id p197so45124885lfa.2 for <>; Tue, 30 Jul 2019 09:18:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7T+VOLbk+kxjTFzF1VoW/xdi+lBc66ocvRUfX3acpYI=; b=jNALAzExVFxxzLg2uN0EGS1skqezqL7HAX6mNTj7Nzmg4RIFAtcRcU7+LRShVWO3Le j9YehH+ZdPoxrvpInuqw4Mc3hVG+ooNFMQgnmqET+5X8AzASZizuFeeG8BoSBZIqQDqt IkJ7cX5QMbRweFWnqsZyLFFtEFYhJCr/ZewpJZYjxzUtExHX+ruF4z1hvOlDNv7novVK N9XZzDre12aOhw8mFwAL5RIrP0uTUZmz7I8QKH1Qo+AvTGSSCP1eRlmzse66crNcxx94 lCFEW/M7o0rbYmQflMLIcK3ZMY+Q2QlmnevVoPJiLWIhxY4FnytlCnPYN1rq6VPF4J8S xm+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7T+VOLbk+kxjTFzF1VoW/xdi+lBc66ocvRUfX3acpYI=; b=YyddanXRdOEoi+CNLKSEK1GiKNZEeom0JIIdnan5CgewxvK42f+clqE5bhS2Tmp+1w 81pLKbdj4b55OyxUsciofz3NfRr/gUUKDbQSl3R4bc2upWfWxoC4qKLAme1TzNnYs8No QdLqUwc9SP2M+xq6MPwuxIrPb+0KC0dn4fvpQQFJcNafAagLHOVyVPO1IHbRg/E2qqSt jbMIg0CZtbdCKERirR5Ix+BikvUQ59ezVztTsBKCoIlF8HOTPDs0nypMYdQwNST1tgfd fvjn3kk6OZVVDfESVV/9YxR3o8WsQN59XniHchKVOY4kwyG5OX+i1u2HbD7j5vJtbgxC gylQ==
X-Gm-Message-State: APjAAAWDjyyia97MpsPiKiPPgWA0IV81YzoRl7Z8bnXOyDP8hO+NNPUv fUCAGiTYIAc3CKi25+SNvpBQB/JjGPFJR84Nafg=
X-Google-Smtp-Source: APXvYqwzUqqUk/T50JbnnV16G0NGIKUaYo0WOc+Jg38bn65DkIFBJ0iV4jjBIFYyq16GnfwulQYCCaIobVnNldFlXuQ=
X-Received: by 2002:a19:2297:: with SMTP id i145mr54422897lfi.97.1564503490366; Tue, 30 Jul 2019 09:18:10 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Watson Ladd <>
Date: Tue, 30 Jul 2019 09:17:57 -0700
Message-ID: <>
To: "Scott Fluhrer (sfluhrer)" <>
Cc: TLS List <>
Content-Type: multipart/alternative; boundary="000000000000cb135b058ee85af8"
Archived-At: <>
Subject: Re: [TLS] Options for negotiating hybrid key exchanges for postquantum
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Jul 2019 16:18:15 -0000

On Tue, Jul 30, 2019, 8:21 AM Scott Fluhrer (sfluhrer) <>;

> During the physical meeting in Montreal, we had a discussion about
> postquantum security, and in particular, on how one might want to negotiate
> several different ‘groups’ simultaneously (because there might not be one
> group that is entirely trusted, and I put ‘groups’ in scarequotes because
> postquantum key exchanges are typically not formed from a Diffie-Hellman
> group).
> At the meeting, there were two options presented:
> Option 1: as the supported group, we insert a ‘hybrid marker’ (and include
> an extension that map lists which combination the hybrid marker stands for)
>                 For example, the client might list in his supported groups
> hybrid_marker_0 and hybrid_marker_1, and there would be a separate
> extension that lists hybrid_marker_0 = X25519 + SIKEp434 and
> hybrid_marker_1 = X25519 + NTRUPR653.  The server would then look up the
> meanings of hybrid_marker_0 and 1 in the extension, and then compare that
> against his security policy.
> In this option, we would ask IANA to allocate code points for the various
> individual postquantum key exchanges (in this example, SIKEp434 and
> NTRUPR653), as well a range of code points for the various hybrid_markers.

> Option 2: we have code points for all the various combinations that we may
> want to support; hence IANA might allocate a code point X25519_SIKEp434 and
> another code point for X25519_NTRUPR653.  With this option, the client
> would list X25519_SIKEp434 and X25519_NTRUPR653 in their supported groups.
>                 In this option, we would ask IANA to allocate code points
> for all the various combinations that we want allow to be negotiated.
> I would like to make an argument in favor of option 1:
>    - It is likely that not everyone will be satisified with “X25519 plus
>    one of a handful of specific postquantum algorithms”; some may prefer
>    another elliptic curve (for example, x448), or perhaps even a MODP group; I
>    have talked to people who do not trust ECC); in addition, other people
>    might not trust a single postquantum algorithm, and may want to rely on
>    both (for example) SIKE and NewHope (which are based on very different hard
>    problems).  With option 2, we could try to anticipate all the common
>    combintations (such as P384_SIKEp434_NEWHOPE512CCA), however that could
>    very well end up as a lot of combinations.
>    - There are likely to be several NIST-approved postquantum key
>    exchanges, and each of those key exchanges are likely to have a number of
>    supported parameter sets (if we take the specific postquantum key exchange
>    as analogous to th ECDH protocool, the “parameter set” could be thought of
>    an analogous to the specific elliptuc curve, and it modifies the key share
>    size, the performance and sometimes the security properties).  In fact, one
>    of the NIST submissoins currently has 30 parameter sets defined.  Hence,
>    even if NIST doesn’t approve all the parameter sets (or some of them do not
>    make sense for TLS in any scenario), we might end up with 20 or more
>    different key exchange/parameter set combinations that do make sense for
>    some scenario that uses tLS (be it in a tranditional PC client/server, a
>    wireless client, two cloud devices communicating or an IOT device).
>    - In addition, we are likely to support additional primitives in the
>    future; possibly National curves (e.g. Brainpool), or additional
>    Postquantum algorithms (or additional parameter sets to existing ones).  Of
>    course, once we add that code point, we’ll need to add the additional code
>    points for all the combinations that it’ll make sense in (very much like we
>    had to add a number of ciphersuites whenever we added a new encryption
>    algorithm into TLS 1.2).

Are people actually going to use hybrid encryption post NIST? The actual
deployments today  for experiment have all fit option 2 and hybrids are
unlikely in the future.

My objection to 1 is it gets very messy. Do we use only the hybrids we both
support? What if I throw a bunch of expensive things together? No reason we
need a hybrid scheme!

It seemds reasonable to me that the combination of these two factors are
> likely to cause us (should we select option 2) to define a very large
> number of code points to cover all the various options that people need.
> Now, this is based on speculation (both of the NIST process, and
> additional primitives that will be added to the protocol), and one
> objection I’ve heard is “we don’t know what’s going to happen, and so why
> would we make decisions based on this speculation?”  I agree that we have
> lack of knowledge; however it seems to me that a lack of knowledge is an
> argument in favor of selecting the more flexible option (which, in my
> opinion, is option 1, as it allows the negotiation of combinations of key
> exchanges that the WG has not anticipated).
> My plea: lets not repeat the TLS 1.2 ciphersuite mess; lets add an
> extension that keeps the number of code points we need to a reasonable
> bound.
> The costs of option 1?
>    - It does increase the complexity on the server a small amount (I’m
>    not a TLS implementor, however it would seem to me to be only a fairly
>    small amount)
>    - It may increase the size of the client hello a small amount (on the
>    other hand, because it allows us to avoid sending duplicate key shares, it
>    can also reduce the size of the client hello as well, depending on what’s
>    actually negotiated)
> IMHO, the small increase in complexity is worth the lack of complexity in
> the code point table, and the additional flexibility it gives.
> _______________________________________________
> TLS mailing list