Re: [TLS] AdditionalKeyShare Internet-Draft
William Whyte <wwhyte@onboardsecurity.com> Thu, 20 April 2017 17:34 UTC
Return-Path: <wwhyte@onboardsecurity.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 B61BA129464 for <tls@ietfa.amsl.com>; Thu, 20 Apr 2017 10:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.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 UUKpSzFhLFH2 for <tls@ietfa.amsl.com>; Thu, 20 Apr 2017 10:33:58 -0700 (PDT)
Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 BB87D1201FA for <tls@ietf.org>; Thu, 20 Apr 2017 10:33:57 -0700 (PDT)
Received: by mail-wr0-x230.google.com with SMTP id w50so16976396wrc.0 for <tls@ietf.org>; Thu, 20 Apr 2017 10:33:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HQxHXe9qDJTlzNQ2vfZ3lzJbmmrbFJ73g54XQyBlcEA=; b=fePWZGeyyeuSHZBsLtkICNewgcD34vApOEYmEU2HiNA+K4Y6I5xIIhWlkS1YITyhHf Y/4xglrHoT1mBbi8qh7Twn/ikNwAodksjv/6bH51NCDMRsiFSttn1g0byXSfhzK5UU/j ee5MGXcv5p2wIn+5/YQSjTTMyH1/8so450UC0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HQxHXe9qDJTlzNQ2vfZ3lzJbmmrbFJ73g54XQyBlcEA=; b=ncGgPxLn5N9vIKU7Q8084aXNIOpzz0RioAdVrHRilvvTqlU7rZ9dKI+YaGTx29H1rD 1EE4CgYQrOviESUA1pgIkcho0CdePWaLIA0AQW+sIf0C9xIEcCKCzf3mP8ChFTlTw40i wP4sOc1WngVmh8jAeV8ER2wBOXKC6EeHUkNDeOilFMqBOqjwVD0vO1ePO1UdKZrhHJE2 ywqAMKITlR89MGwXqR4Plrt05JQLGQfXRmUrnWuqYUR15KO5wyd4oAhJh4xAsEkqT2FA ETwcK+HbmSUEJumSNnJRFyoHr5FD3cxZ/5hGlygt2EWFqB6XmSy/3IB5oUeKXMRPs17p BbFA==
X-Gm-Message-State: AN3rC/4fEL+nUV8fPReZR2Qf91CKjxKjWM5qJLyftGtAQAPQXoHl5oKq bje9F5+xQyrtNkd3UxA/laGPPRQ0Ag==
X-Received: by 10.223.164.6 with SMTP id d6mr8281881wra.144.1492709636209; Thu, 20 Apr 2017 10:33:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.72.130 with HTTP; Thu, 20 Apr 2017 10:33:35 -0700 (PDT)
In-Reply-To: <CAND9ES3uCdU5cUO7hQ3muHmAqaRCnBHQ=ci+0_uWS1rfsgCX=Q@mail.gmail.com>
References: <E8836EB8-EFC4-4506-BCBB-2F4FE9BA075F@gmail.com> <cf779520cb68499385ae3440b5dbbe3e@XCH-RTP-006.cisco.com> <CAND9ES3uCdU5cUO7hQ3muHmAqaRCnBHQ=ci+0_uWS1rfsgCX=Q@mail.gmail.com>
From: William Whyte <wwhyte@onboardsecurity.com>
Date: Thu, 20 Apr 2017 13:33:35 -0400
Message-ID: <CAND9ES0sYKJm6Q8GprWTG-+eit_-K0Rrqut03xOVi1x-s_SpZg@mail.gmail.com>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
Cc: Douglas Stebila <dstebila@gmail.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="f403045f13889e8ea7054d9c8ba8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/h7iTtUjwZJiF-zkfYPafc1LHOi4>
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: Thu, 20 Apr 2017 17:34:01 -0000
Sorry! Link to the most recent version... https://tools.ietf.org/html/ draft-whyte-qsh-tls13-04 William On Thu, Apr 20, 2017 at 1:08 PM, William Whyte <wwhyte@onboardsecurity.com> wrote: > Link to that draft: https://tools.ietf.org/html/draft-whyte-qsh-tls13-02 > > Cheers, > > William > > On Wed, Apr 19, 2017 at 2:42 PM, Scott Fluhrer (sfluhrer) < > sfluhrer@cisco.com> wrote: > >> >> > -----Original Message----- >> > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Douglas Stebila >> > Sent: Monday, April 17, 2017 2:24 PM >> > To: <tls@ietf.org> >> > Subject: [TLS] AdditionalKeyShare Internet-Draft >> > >> > Dear TLS mailing list, >> > >> > We have posted an Internet-Draft >> > https://tools.ietf.org/html/draft-schanck-tls-additional-ke >> yshare-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. >> >> We have a draft with similar goals; draft-whyte-qsh-tls13 . It also >> tries to achieve Quantum-safeness through multiple key exchange mechanisms; >> however in terms of protocol, it works somewhat differently. You have the >> 'normal' key exchange (as exists in the protocol), and a second one on the >> side. We allows the client to define a hybrid group (which consists of >> several key exchanges done in parallel). One of our goals was to stay >> within the existing TLS architecture as much as possible (and thus limiting >> the changes needed to the TLS state machine and parsing logic); things such >> as modifying the key derivation mechanism (such as you do) were considered >> to be too large. >> >> It may be worth your while to go through our draft,,, >> >> > >> > 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. >> >> Our draft allows for that naturally. >> >> As for the need, well, I expect that some will want it. We don't have >> any postquantum key exchanges that are both practical and really well >> trusted (at least, to the same extent that (EC)DH is); I would expect that >> some people will want to spread their risk and do (for example) x25519 + >> Frodo + SIDH. >> >> > >> > - 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 >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > >
- Re: [TLS] AdditionalKeyShare Internet-Draft David Benjamin
- [TLS] AdditionalKeyShare Internet-Draft Douglas Stebila
- Re: [TLS] AdditionalKeyShare Internet-Draft Eric Rescorla
- Re: [TLS] AdditionalKeyShare Internet-Draft Benjamin Kaduk
- Re: [TLS] AdditionalKeyShare Internet-Draft Douglas Stebila
- Re: [TLS] AdditionalKeyShare Internet-Draft Scott Fluhrer (sfluhrer)
- Re: [TLS] AdditionalKeyShare Internet-Draft William Whyte
- Re: [TLS] AdditionalKeyShare Internet-Draft William Whyte