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

David Benjamin <davidben@chromium.org> Tue, 30 July 2019 18:59 UTC

Return-Path: <davidben@google.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 BEC35120196 for <tls@ietfa.amsl.com>; Tue, 30 Jul 2019 11:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.15
X-Spam-Level:
X-Spam-Status: No, score=-9.15 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 yKtgFVU5bE_B for <tls@ietfa.amsl.com>; Tue, 30 Jul 2019 11:59:38 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D99120110 for <tls@ietf.org>; Tue, 30 Jul 2019 11:59:38 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id t8so47379556qkt.1 for <tls@ietf.org>; Tue, 30 Jul 2019 11:59:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OQWVlSt6nRAEkNMtQBpeuoeyjkVqHv7CYYc+dglmhLU=; b=A/m6kuopVr4QJvAmWvMs8MOe+M8Yqpu4+7frjKGiy/9TCIgHIEyshNd1orsakEb8KM vl6wRfNdpXp/6YaZZto3kvRmI+faulKzoXSC9EiOWLLSPXTB08M+1OKMoTLlnOk7VeQx 1ALEepiK0zLVCTqdpz/sf/npRXKjpzvfbnMOk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OQWVlSt6nRAEkNMtQBpeuoeyjkVqHv7CYYc+dglmhLU=; b=kgJHNYkYNHnWlrbP0wKAWHgeOwnNWEz2MLxdam9hWu5QIHm/1cZtuJkvsDVfJ9QJ8u LIOlNApP2EGSNxLSgGDBL4xgPXvSLDwGY7vetAh3mwKk/wN86f4CD9PwuipEPrG3Yx+a 60rLZPMca9fa2JWH/uhXohpGZqKFM5Yy5A71wDbU1I+K0Wbhr2wR+aMlT1DnIo2ZiW3E 4pI8nM4Jd96udUEVw7Gjw1Q4amohet0K9adPbClPCrohe4/O3RA8o5WQsKYbt3qn+FCu mHZ5HWFul7MggU0s5nAuf7t21x5OVKZbtarGVi9ItMmxjgLAhQ5yOBBH20C5lFESRKY+ 3ySg==
X-Gm-Message-State: APjAAAVrxoxZGhVvA6fJW8C7NZYMxn2xkPOAEhmNwvML1L3vogn5A6XR f5L0JY7yGVef7YP+Va6yZxhMZ7+H88kfhy9zz/rl
X-Google-Smtp-Source: APXvYqwfTW53mvFlQEtIccdj0KuhkA6uobJ1u1HNUTaXU52a2fxkNu8BArWn5QU93pN8e2RZ0GhHH9NJR2YvPvUrf44=
X-Received: by 2002:a37:a14e:: with SMTP id k75mr79027428qke.65.1564513177209; Tue, 30 Jul 2019 11:59:37 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <DM5PR2101MB09177EFFFB5C2D64556724848CDC0@DM5PR2101MB0917.namprd21.prod.outlook.com>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 30 Jul 2019 14:59:21 -0400
Message-ID: <CAF8qwaB5EoG8uJGrmpr=HU-5DoEQWFxuuph6zSNk4+HjPdz_sg@mail.gmail.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Watson Ladd <watsonbladd@gmail.com>, TLS List <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002cf405058eea9c46"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Xs3FBi-RNEIvh0-ZaXvszGGLIoI>
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 18:59:42 -0000

The nuisance with just a flag is the client can't express [what I think
are] reasonable preferences. It should be able to say things like:

* Don't do X25519 + P-256. This is just silly.
* Don't do PQ1 on its own. I really want the PQ scheme paired with
something more established.
* Don't do PQ1 + PQ2. I said something more established, please.
* PQ1 + X25519 is cool. I like that combo.
* Don't do PQ1 + X25519 + P-256. Why are you doing three of these?
* Don't do PQ1 + PQ2 + PQ3 + PQ4 + X25519 + P-256 + P-384 + FFDHE2048 +
FFDHE3072, oww my head.

We can make things implicit by categorizing named groups and building all
this into the protocol itself, but I think that's an unnecessary moving
part.

On Tue, Jul 30, 2019 at 2:48 PM Andrei Popov <Andrei.Popov@microsoft.com>;
wrote:

> Given these options, I also prefer option 2, for some of the same reasons.
>
>
>
> For my understanding though, why not have the client advertise support for
> hybrid-key-exchange (e.g. via a “flag” extension) and then
> KeyShareServerHello can contain two KeyShareEntries (essentially, using the
> same format as KeyShareClientHello? This would solve the Cartesian product
> issue.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* TLS <tls-bounces@ietf.org>; *On Behalf Of * David Benjamin
> *Sent:* Tuesday, July 30, 2019 11:24 AM
> *To:* Watson Ladd <watsonbladd@gmail.com>;
> *Cc:* TLS List <tls@ietf.org>;
> *Subject:* Re: [TLS] Options for negotiating hybrid key exchanges for
> postquantum
>
>
>
> I think this underestimates the complexity cost of option 1 to the
> protocol and implementations. Option 1 means group negotiation includes
> entire codepoints whose meaning cannot be determined without a parallel
> extension. This compounds across everything which interacts with named
> groups, impacting everything from APIs to config file formats to even UI
> surfaces. Other uses of NamedGroups are impacted too. For instance, option
> 2 fits into draft-ietf-tls-esni as-is. Option 1 requires
> injecting hybrid_extension into ESNI somehow. Analysis must further check
> every use, say, incorporates this parallel lookup table into
> transcript-like measures.
>
>
>
> The lesson from TLS 1.2 code points is not combined codepoints vs. split
> ones. Rather, the lesson is to avoid interdependent decisions:
>
>
>
> * Signature algorithms in TLS 1.2 were a mess because the ECDSA codepoints
> required cross-referencing against the supported curves list. The verifier
> could not express some preferences (signing SHA-512 with P-256 is silly,
> and mixing hash+curve pairs in ECDSA is slightly off in general). As
> analogy to option 1's ESNI problem, we even forgot to allow the server to
> express curve preferences. TLS 1.3 combined signature algorithm
> considerations into a single codepoint to address all this.
>
>
>
> * Cipher suites in TLS 1.2 were a mess because they were half-combined and
> half-split. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 said to use some ECDHE
> key exchange, but you need to check if you have a NamedGroup in common
> first. It said to use ECDSA, but you need to check signature algorithms
> (which themselves cross-reference curves) first. Early drafts of TLS 1.3
> had it even worse, where a TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 full
> handshake morphed into TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 on resumption.
> Thus, TLS 1.3 cipher suites negotiate solely AEAD + PRF hash.
>
>
>
> In fairness to TLS 1.2, some of this was a consequence of TLS 1.2's
> evolution over time as incremental extensions over SSL 3.0. And sometimes
> we do need to pay costs like these. But hybrid key exchanges fit into the
> NamedGroup "API" just fine, so option 2 is the clear answer. Code points
> are cheap. Protocol complexity is much more expensive.
>
>
>
> It's true that standards are often underspecified. This means the IETF
> should finish the job, not pass all variations through. RSA-PSS is a clear
> example of what to avoid. It takes more bytes to merely utter "RSA-PSS with
> SHA-256 and usual parameters" in X.509 than to encode an entire ECDSA
> signature! We should not define more than a handful of options, regardless
> of the encoding..
>
>
>
> On Tue, Jul 30, 2019 at 12:18 PM Watson Ladd <watsonbladd@gmail.com>;
> wrote:
>
>
>
> On Tue, Jul 30, 2019, 8:21 AM Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com>;
> wrote:
>
> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C8b45740f081f44820a4c08d7151b30e3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637001079003849042&sdata=swB52kH%2Fx7DvLNaX9EAyHcNf7VuiXRRUsx%2Ftdn0e1S4%3D&reserved=0>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C8b45740f081f44820a4c08d7151b30e3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637001079003859035&sdata=OHEwC6itmwbrqT1TpByKoytOuhKOIghix7SzMkPdXvQ%3D&reserved=0>
>
>