[TLS] AdditionalKeyShare Internet-Draft

Douglas Stebila <dstebila@gmail.com> Mon, 17 April 2017 18:23 UTC

Return-Path: <dstebila@gmail.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 AAE0612EAF1 for <tls@ietfa.amsl.com>; Mon, 17 Apr 2017 11:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7qScU-hZeZJn for <tls@ietfa.amsl.com>; Mon, 17 Apr 2017 11:23:42 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 1612A131761 for <tls@ietf.org>; Mon, 17 Apr 2017 11:23:36 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id a140so11914394ita.0 for <tls@ietf.org>; Mon, 17 Apr 2017 11:23:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=FpwrN5Vd9tI78IkpefuMLEcIUk4Rumb5kdk8uIw2sBw=; b=C87HehWvfyqTZbuHme1MJuAPW+Z8jylgHGjNDOBsLKWFq7QWefPmsqIt1U2luqDj0i RxXrxpP+gVdjmTRAut1i3LD2CxF4sYIenHCCd7i9ZyhiRAnytdLIIyU4EDy01NdcdYGc SoEJTrwkwuDbIgkuHDJmTiNkVD0MuUinFXk71bFrwsYdxoNGSduGhIKWIEswwsYkQn4d KuXn8/DqTfP988pmVD4lb15vHgJUMu9CJBPi+aBKQCsErXDXBfh0IK0WQQ05F4YG7af0 bVbUnv6l/xhhYXIdNiYZUZ+S5g+2tYQDt1Bia7ldUb1npT6huvUp9cdv4e5tqJb+Qo0r +aWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=FpwrN5Vd9tI78IkpefuMLEcIUk4Rumb5kdk8uIw2sBw=; b=Uaxs7ch329Eo2UB2W1wVAUfvGRE+NXJbzxu+UqyiaZ1cuUSFdae9CXJkgLBO6/2nvW kpG9Z5TW2NKIzxAT7Cs/Pba6iaAEGQujcE/CIW3pqbbv2CTfhVg/DprJ5OCSTEfRgmgH O78hte4YZPxkKR0KPMBRMY9PtxJlrR7YQ0KaV3Fsd1MZFxcPmsPn9rJnXuUce959SmoT 1GwrWLA9JWsVIbM1zuYqON0DMKjMDKYPa+vJN/EN1pgyyKBZYbzT1tah1E3YUGtL+Rmy 0fUZDMVrZtpgvmKeytG7tEgpzVsK2zsB5A7mgNtSWfQJGo7wvv3aZqUcsDwYc5vg6xOo OAAA==
X-Gm-Message-State: AN3rC/7bOjKY4URvRjJ2UVc07kXUb5l8YnEPVSaX5WBUNZ1+EC2GHDqZ 6j5Yk7mGppr62Ew7QE8=
X-Received: by 10.36.2.205 with SMTP id 196mr9813497itu.63.1492453415153; Mon, 17 Apr 2017 11:23:35 -0700 (PDT)
Received: from stebila-imac.cas.mcmaster.ca (stebila-imac.cas.McMaster.CA. [130.113.68.195]) by smtp.gmail.com with ESMTPSA id f196sm6261571itc.2.2017.04.17.11.23.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 11:23:34 -0700 (PDT)
From: Douglas Stebila <dstebila@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <E8836EB8-EFC4-4506-BCBB-2F4FE9BA075F@gmail.com>
Date: Mon, 17 Apr 2017 14:23:32 -0400
To: "<tls@ietf.org>" <tls@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/g0xNgUZYZqc9mDK0yTcEIHV4ob8>
Subject: [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 18:23:44 -0000

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