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
>>
>
>