Re: [TLS] AdditionalKeyShare Internet-Draft
Eric Rescorla <ekr@rtfm.com> Mon, 17 April 2017 20:31 UTC
Return-Path: <ekr@rtfm.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 04CD312946A for <tls@ietfa.amsl.com>; Mon, 17 Apr 2017 13:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 ziZbPIeKHHpE for <tls@ietfa.amsl.com>; Mon, 17 Apr 2017 13:31:32 -0700 (PDT)
Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (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 0BA6612945D for <tls@ietf.org>; Mon, 17 Apr 2017 13:31:32 -0700 (PDT)
Received: by mail-yb0-x231.google.com with SMTP id m133so32655386ybb.1 for <tls@ietf.org>; Mon, 17 Apr 2017 13:31:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EJIP5nOiy2FldfEvRcDk6Y2boNHy5My6b8HimRmEN3k=; b=R+s/dosJuxEB3vm9Mseh8FDTZdxbSjRG/WNYNBwedBeW/FGHebUt0Oi0MuUM+m24tV zOAZsZ+LAe1oCNPAqZ+GjL1W17esGqgLqiXiznogNzHRrBJ/EQ6qxHNgx7bG6YOLXhEn HzsKQ90UBL/pPYBBB4hBJ8LBdvLlGCm8MGVduVcetjM/qja+qfeX0NMMKY2MBNQfnC1k iwhD81an9tJebeIw/lr9QJdrYGckWoXfeslb40irgNy06piq5reh+gWOB1b31zDPWIlc I/CiUHAjVCwkTIdJkwttdmJ41zLN724QFqfB9s9QoZOWxgXS6ycwRD5Ln63G+DEgZstj Dvpw==
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=EJIP5nOiy2FldfEvRcDk6Y2boNHy5My6b8HimRmEN3k=; b=uaszfGCsqyEm92selm9ZVhPOOu+GfFcQbKs7ad4bOre9frJvPeHkPHflZk2go2UHZp scvbCT/pBDGhOpUdCdn0vXWDRppaT3zrhONhXqRTTqjnPt0QKhb/DkjxkygipoY19tEA ixQlUqnu1aGMocTm0Liv53HhXd07IgdR4fUKBPZZuVKsVk7cpnHP6hG7LTs0/O55AIms 2vkMMkVwOn6zzhhX+sO263whG5CY5yGkq/CRlC/Qg8EM/upqLnlG/31uhAuAnPMR5bpm cy+EX0JH2wKlOlJiHv+gimHujgMS/gwHzyx9+VqUrhz2k95dm2qoZv5tkMdp4mHJZk9V oTFA==
X-Gm-Message-State: AN3rC/6v8TyVVG6nE0O3UpYC79mydONqTX9rzXX5QY8niqGHWd7beFb/ go/9rQvl0SgNZdlCpSDu+avv0VZJ+A==
X-Received: by 10.37.78.195 with SMTP id c186mr16597584ybb.180.1492461091204; Mon, 17 Apr 2017 13:31:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.113.7 with HTTP; Mon, 17 Apr 2017 13:30:50 -0700 (PDT)
In-Reply-To: <436c8c50-6a32-8d4e-d666-b96684847c55@akamai.com>
References: <E8836EB8-EFC4-4506-BCBB-2F4FE9BA075F@gmail.com> <CAF8qwaB74gFFdc6jQ0ySddYO4FQJmZdDS=uo5yF5UzQ+5sTP=A@mail.gmail.com> <E0EDAFAD-E0B5-4BBD-8553-1AC1E448E5D6@gmail.com> <436c8c50-6a32-8d4e-d666-b96684847c55@akamai.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 17 Apr 2017 16:30:50 -0400
Message-ID: <CABcZeBNjjAjJGiB=H_833V2we90wqeZp6ARWY7yV6M2mjRcWfw@mail.gmail.com>
To: Benjamin Kaduk <bkaduk@akamai.com>
Cc: Douglas Stebila <dstebila@gmail.com>, David Benjamin <davidben@chromium.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a113e88fa2ef8c6054d62ad38"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/B5nBWseL4Mhk1eKteH55VMLSlt4>
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 20:31:34 -0000
I agree with David here. ISTM that if we discover that this is turning a lot of problems, we can presumably add an extension like the one proposed here at some later point. -Ekr On Mon, Apr 17, 2017 at 4:14 PM, Benjamin Kaduk <bkaduk@akamai.com> wrote: > On 04/17/2017 02:44 PM, Douglas Stebila wrote: > > Hi David, > > Thanks for the feedback. > > 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. > > > Defining combined NamedGroups, like in the Google New Hope experiment, > also incurs a combinatorial explosion, this time in the number of > NamedGroups. Given that TLS 1.3 has taken the approach of splitting off > each component of a TLS 1.2 ciphersuite into its own negotiable component > to avoid combinatorial explosion in standardized values, separately > negotiating each parallel key share mechanism seemed to us to follow the > TLS 1.3 design approach. > > > You only get the combinatorial explosion if you let it happen. A lot of > the possible combinations wouldn't make much sense, and would not need to > be defined. TLS 1.3 also tries to limit the possible combinations in some > aspects, presenting just a few good choices with clear trade-offs. > > It also requires implementations answer silly questions like: > - What happens the server selects two New Hopes with no X25519? X25519 and > P-256 together? > > > In our draft, KeyShare and AdditionalKeyShare form disjoint pools of > NamedGroups from which one element can be selected. If the client offers > say P256 and X5519 in KeyShare and NewHope in its AdditionalKeyShare, your > first problem cannot happen. If the client offers NewHope in both pools, > then the situation you propose could happen. This does not negatively > impact compatibility or security, although there is obviously no value in > doing two NewHopes compared to a single NewHope. I don't think we've put > in a MUST NOT/SHOULD NOT here, but we could add that. > > > That's pushing complexity from the spec into implementations; we have a > lot of evidence to suggest that not all implementations will get it right. > > > - How can I plausibly expose this complex array of options to the consumer > of my TLS library? > > Yes, there is a complex array of options: > - which algorithm(s) the client views as "must have" > - which algorithm(s) the client views as "would like to have" > - which algorithm(s) should/should not happen at the same time > > If this functionality is encapsulated anywhere in TLS, then that > complexity needs to incorporated somewhere, either already in compound > NamedGroups or in configuration of the parallel key share mechanism. As I > mentioned above, we thought that combinatorial explosion of NamedGroups was > not the TLS 1.3 way. However, we are open to considering that if there's a > clear preference for it. > > > I would rather leave the complexity in the NamedGroups registry. > > -Ben > > _______________________________________________ > 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