Re: [TLS] AdditionalKeyShare Internet-Draft

David Benjamin <davidben@chromium.org> Mon, 17 April 2017 19:14 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 E2DC8131770 for <tls@ietfa.amsl.com>; Mon, 17 Apr 2017 12:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 ePV1pt4U2N8C for <tls@ietfa.amsl.com>; Mon, 17 Apr 2017 12:14:38 -0700 (PDT)
Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (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 A22991315AE for <tls@ietf.org>; Mon, 17 Apr 2017 12:14:38 -0700 (PDT)
Received: by mail-pg0-x229.google.com with SMTP id z127so12425619pgb.1 for <tls@ietf.org>; Mon, 17 Apr 2017 12:14: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; bh=wWvms78Q7qk6wBmdGsFD80GqtGPTyZqLPNGoQcwe9/4=; b=SE+sYkhsfhndB4CRGzOukgVDljZGL/72sgR0U6tPc5Wrs2vclcS4s40khZP5eVnNQ7 GQw+tRYDRRgMYjE/AexHHkl3Th/g45Z/yWbvYvIn2WpMruSLccmNtexcdA88ULzYZX6p vHg7vxdE2/yClk2D1MH7lqDUUcdY4gYN06mMY=
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; bh=wWvms78Q7qk6wBmdGsFD80GqtGPTyZqLPNGoQcwe9/4=; b=PE5lbdEEF3EvAvHIVve1QPNA9euBqIqg9FZZldXrfCVuqRrGSyYULSFJ98vA90rrhB nfupQhvPJlTRCKAoWKqIGtxPl228ptPGWTpsryNxklczulxYlg4TyHyJgVTCNYEpuJ7V dxzaJnwiboHCu6UOyjiTVglthMri9fNP2bsx339WLM2/5v7Ry3yu/WiWqjigRCUNf6Wk pVfd60h67apoXNgUBubcPq06k8ODpOSWHXuU2g2yG4XDh9710w6lRTaYm7spegObGXEZ zMTtB6oepq5ZtZGTjX/XUEs/qdJVaz3139fOvGoYwlsJrS9glHOnM+cBZtgtr3oSExxv C5aw==
X-Gm-Message-State: AN3rC/7OGG6nr/V+MA0vv4QLkiitRuwiYpRxsHTCc5aGvzztJmHG+Flt YRUf4vXEZWe/eGJQOCls7trWhhkrzZfQKwY=
X-Received: by 10.84.140.129 with SMTP id 1mr18153365plt.11.1492456478123; Mon, 17 Apr 2017 12:14:38 -0700 (PDT)
MIME-Version: 1.0
References: <E8836EB8-EFC4-4506-BCBB-2F4FE9BA075F@gmail.com>
In-Reply-To: <E8836EB8-EFC4-4506-BCBB-2F4FE9BA075F@gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Mon, 17 Apr 2017 19:14:26 +0000
Message-ID: <CAF8qwaB74gFFdc6jQ0ySddYO4FQJmZdDS=uo5yF5UzQ+5sTP=A@mail.gmail.com>
To: Douglas Stebila <dstebila@gmail.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c11a09238ea9c054d619a76"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/OiObWi3qCKcD4coXZscZqBImOvg>
Subject: Re: [TLS] AdditionalKeyShare Internet-Draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 17 Apr 2017 19:14:41 -0000

This seems overly complicated. Why implement a parallel key share mechanism
rather than merely defining a new NamedGroup value?

Using your example of Google's recent New Hope experiment, I would imagine
defining, say, NamedGroup.cecpq1. Let its key_shares be the concatenation
of New Hope and X25519 public values, and let the resulting shared secret
be some combination of the two resulting keys.

This avoids changing the key schedule or protocol logic and slots in nicely
into the existing arrangement. The AdditionalKeyShare proposal has more
moving parts and combinatorial combinations to test and worry about. It
also requires implementations answer silly questions like:
- What happens the server selects two New Hopes with no X25519? X25519 and
P-256 together?
- What happens if the client offers New Hope in the normal key shares slot
and X25519 in the additional one?
- What happens if the client only offers New Hope and not X25519?
- How does a client express that it's not willing to do New Hope without
ECDH? What if the server sends a HelloRetryRequest for New Hope in the main
slot and does not select X25519?
- How can I plausibly expose this complex array of options to the consumer
of my TLS library?

David


On Mon, Apr 17, 2017 at 2:23 PM Douglas Stebila <dstebila@gmail.com> wrote:

> Dear TLS mailing list,
>
> We have posted an Internet-Draft
>     https://tools.ietf.org/html/draft-schanck-tls-additional-keyshare-00
> for using an additional key share in TLS 1.3.  The intended use case is to
> provide support for transitional key exchange mechanisms in which both a
> pre-quantum algorithm (e.g., ECDH) and a post-quantum algorithm are used.
> (Google's experiment with New Hope in 2016 had such an arrangement.) Our
> draft
> replicates the functionality of the KeyShare extension in a new extension
> called
> AdditionalKeyShare. Like KeyShare, the client's AdditionalKeyShare
> contains a
> vector of KeyShareEntry structs. The server can respond with a single
> matching
> KeyShareEntry in the AdditionalKeyShare extension of its ServerHello. The
> resulting additional shared secret is included in the TLS key schedule
> after the
> ECDH shared secret.
>
> While the motivation for our Internet-Draft is to facilitate the
> transition to
> post-quantum algorithms, our Internet-Draft does not specify any
> post-quantum
> algorithms.
>
> There are a couple of items for discussion related to this draft:
>
> - We only provide a mechanism for a single AdditionalKeyShare, thus
> leading to
>   the session establishing at most PSK + ECDHE + 1 additional shared
> secret.  Is
>   there a value in even more shared secrets than that?  Will someone want
>   to include more than one post-quantum algorithm?  If so, our draft could
> be
>   adapted to have AdditionalKeyShare1, AdditionalKeyShare2, etc., but we
> did not
>   want to add that complexity unless there was desire for it.
>
> - TLS 1.3 allows the client to restrict the use of PSKs that they provide
> in
>   ClientHello through the "psk_key_exchange_modes" extension. The client
> may,
>   for instance, request that the PSK only be used in a PSK+(EC)DHE mode,
> so as
>   to ensure that the resumed session has forward secrecy.  It is unclear
> the
>   best way to reconcile this with support for multiple key shares; we
> outline
>   some possibilities in Section 4 of our Internet-Draft, and we welcome
> input.
>
> We have also created a pull request to TLS 1.3 draft 19 which includes a
> clarification on how additional secrets are to be included in the TLS key
> schedule.
>     https://github.com/jschanck/tls13-spec
>
> John and Douglas
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>