Re: [TLS] PR #604 Change "supported_groups" to "supported_kems"

William Whyte <wwhyte@securityinnovation.com> Tue, 13 September 2016 18:27 UTC

Return-Path: <wwhyte@securityinnovation.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 00B5A12B00E for <tls@ietfa.amsl.com>; Tue, 13 Sep 2016 11:27:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=securityinnovation.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 j80YBhhhVZXM for <tls@ietfa.amsl.com>; Tue, 13 Sep 2016 11:27:12 -0700 (PDT)
Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 84978120727 for <tls@ietf.org>; Tue, 13 Sep 2016 11:27:12 -0700 (PDT)
Received: by mail-vk0-x22e.google.com with SMTP id f76so193257292vke.0 for <tls@ietf.org>; Tue, 13 Sep 2016 11:27:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hQSkSrMjC5utNVIge3n7hWDRPOometh9leZVAZw+ANA=; b=SPgLL8ZGlniUru4oPXs/6R0MZDvtePxhkhHvvfPDXY68U0mNoTq+EHagxgMSqlp5ua YP5uQTznV+Fw2P8HBxNFpMhKgTlENcSPSU85Hj04kzXzMOmuJNX/jrHA155AUnXz2Z9O czrKYuu1TJsLyAm7NEp5IpsHe+r48h1OpfZeM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hQSkSrMjC5utNVIge3n7hWDRPOometh9leZVAZw+ANA=; b=JVFQPjbP505uGKSdq7ZrgKYQkXgbCYBcxMnddDWOY3liuKD+WZg6Wm55xp0k9mHAgL ulPNIBRgQPn18OISuUwsrbtdqjzG3XnLDAXH3QW1xVLBsxiCjYF4TWx8goTzzgbTEqP4 i1BG/VJjCAMRQhQcWt4FTsnAt7pocqnabu20C4Tr3Gluqg0yGAwP5AP6KO++nSk7Fqlj uPqxtu+VKNSbEBKyVCLRg4kmVeUUQ8Xu1GKbadGD6ChKxy+IWNroLbETTiLYh7tkGyCa bIqWl9fJ4QDnRolnuWxOh9GR+ElNFD6aMws08oIrPhUNiklZpb87Tel1D5L6H/3an3Xi hg5A==
X-Gm-Message-State: AE9vXwOyi16P+WCUx1Fi6lyoZprZQTfNTHl/Xt+T79+qOFMq/8Jadfwq+4nD9a5EaNuM6anH73GF3rdz4euS6ZQZ
X-Received: by 10.31.34.70 with SMTP id i67mr2325011vki.155.1473791231487; Tue, 13 Sep 2016 11:27:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.6.40 with HTTP; Tue, 13 Sep 2016 11:27:09 -0700 (PDT)
In-Reply-To: <1E1A7A63-5A74-416F-883C-665F15F176CD@sn3rd.com>
References: <CAB20dTt23w5oJX+i7kM1g5db=q33Af+51AH5Z0xnnptpyX90jw@mail.gmail.com> <1E1A7A63-5A74-416F-883C-665F15F176CD@sn3rd.com>
From: William Whyte <wwhyte@securityinnovation.com>
Date: Tue, 13 Sep 2016 14:27:09 -0400
Message-ID: <CACz1E9owJzNx9hejL4spcoBqENjoeHwd4YpLM0CtmvQVjoL5qA@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Content-Type: multipart/alternative; boundary=001a113dc21ad38712053c67c25a
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/g2Py11XZxhUpXeHLTJFcg72XJ6c>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] PR #604 Change "supported_groups" to "supported_kems"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 13 Sep 2016 18:27:15 -0000

I'd like to just check and see if there are any objections to this PR.
There seems no reason to bake a particular cryptographic family into our
terminology. This is a low-cost change that will save us from looking silly
in a few years time.

Cheers,

William

On Tue, Sep 13, 2016 at 1:19 PM, Sean Turner <sean@sn3rd.com> wrote:

> There appears to be no consensus to adopt the change proposed by this PR.
>
> The small condolence here is that the name+semantics for this extension
> has been changed once before and if the extension really needs to be
> renamed in 5-7 years we’ve got precedence for doing so.
>
> spt
>
> > On Aug 29, 2016, at 15:52, Zhenfei Zhang <zzhang@securityinnovation.com>
> wrote:
> >
> > Hi list,
> >
> >
> >
> > I have created a pull request
> >
> > https://github.com/tlswg/tls13-spec/pull/604
> >
> >
> >
> > I would like to suggest that we change the terminology "NamedGroup" to
> "KeyExchangeMethod".
> >
> >
> >
> > In [1], it is suggested that we redefine the syntax, which leads to the
> separation of public key crypto
> >
> > and symmetric crypto during a handshake. Because of this separation, new
> terminology was defined
> >
> > for key exchange algorithms and authentication algorithms for public key
> crypto in the key exchange
> >
> > extension. "NamedGroup" was used to refer the underlying key exchange
> parameters, which comes
> >
> > from the "Supported Elliptic Curves" in previous versions.
> >
> >
> >
> > The use of "NamedGroup" implicitly requests the key exchange algorithm
> to be Deffie-Hellman type.
> >
> > While it is safe for now, it would be nice to have some crypto agility,
> and future proof. It would make
> >
> > the transition to other key exchange primitives (such as lattice based
> key exchange) or methods
> >
> > (such as key encapsulation mechanism) easier in the future, if we do not
> restrict the key exchange
> >
> > by certain "Group".
> >
> >
> >
> > Knowing that NIST has planned to standardize quantum-safe cryptography
> within 7 years of time
> >
> > (which can and should be accelerated), and those algorithms cannot be
> described in terms of "group",
> >
> > the current terminology will due for a redesign by then. So I would
> suggest to change the
> >
> > "NamedGroup" now rather than later.
> >
> >
> >
> >
> > Overall, this will have the following impact
> >
> >
> >
> > 1. HelloRetryRequest
> >
> >
> >
> > Change HelloRetryRequest structure to
> >
> >
> >
> > struct {
> >
> > ProtocolVersion server_version;
> >
> > KeyExchangeMethod selected_kem;
> >
> > Extension extensions<0..2^16-1>;
> >
> > } HelloRetryRequest;
> >
> >
> >
> > 2. Negotiated Groups
> >
> >
> >
> > Throughout, change "supported_groups" to "supported_kems"; change
> "NamedGroupList" to
> > "KeyExchangeMethodList"; change "named_group_list" to "kem_list"; change
> NamedGroup to
> >
> > KeyExchangeMethod
> >
> >
> >
> > 3. Key Share:
> >
> > Change KeyShareEntry structure to
> >
> >
> >
> > struct {
> >
> > KeyExchangeMethod kem;
> >
> > opaque key_exchange<1..2^16-1>;
> >
> > } KeyShareEntry;
> >
> >
> > [1] https://github.com/ekr/tls13-spec/blob/
> 15126cf5a08c445aeed97c0c25c4f10c2c1b8f26/draft-ietf-tls-tls13.md
> >
> >
> >
> > Thanks for your time.
> >
> >
> >
> > Zhenfei Zhang
> >
> > _______________________________________________
> > 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
>