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

Kyle Rose <krose@krose.org> Tue, 13 September 2016 19:28 UTC

Return-Path: <krose@krose.org>
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 85FBC12B050 for <tls@ietfa.amsl.com>; Tue, 13 Sep 2016 12:28:56 -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=krose.org
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 Bl17zvg6NPHf for <tls@ietfa.amsl.com>; Tue, 13 Sep 2016 12:28:52 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 7C8D112B040 for <tls@ietf.org>; Tue, 13 Sep 2016 12:28:51 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id t7so83756449qkh.2 for <tls@ietf.org>; Tue, 13 Sep 2016 12:28:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o1YuymIRIbOEY1k1RnME7rvhfpb7a4/GVEXg1ysvg6I=; b=CFZckmg+AVKdokqy667y/E7Ld2o/5TLSUYkX30WBudKhwqVmp6CnxRJS4y1EvbmYsY JF8As169EWBigp+u/+j3QOs6quiyxuKR1u7XZL57PPffMlIvCbHLbexgz6zdd1shF5SW AEs5Pg0jOxGlEtHs8KvJx+w/dUYkOFJtHSdUM=
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=o1YuymIRIbOEY1k1RnME7rvhfpb7a4/GVEXg1ysvg6I=; b=BALh46NB/81v/+iA6bjq3p7Tp8npDNwlFg7HO9oFYzTQomCKDPKyUO8uBppxb6feyy tSeZ6DrV7nO3DusQGa/7/HGpi5dg/h8Rzf/T0ITsnajwrzMvO3ahjCF8sqp//7bpAbJ4 mpuOBhT4LmpoJQtynxdDrBC6YSVlNbuy+c1uw6w3C727J9RcwSl6g0o0KriimPPhAdsd YJoVsZCLpDXusw0nHqPbffTXOzW7GEXnH/eIE5x0azPkPw9o/F9yk777LzRFp6FALXZn Uu9Bwl52NWwOrbK3pn3jTbCIdtZUiZtQ2DghRQhJik+SFEEUI8od8tdSrsPKZqLRnrfj gV8w==
X-Gm-Message-State: AE9vXwPFH6teUcA7ZhkuPAXrBVKZ6jJw91mN3ReTLUdkG538zcpbBECKcO7/kIjgW0gnY8lKxu85dctbhQtPig==
X-Received: by 10.55.198.204 with SMTP id s73mr3070293qkl.200.1473794930591; Tue, 13 Sep 2016 12:28:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.104.18 with HTTP; Tue, 13 Sep 2016 12:28:49 -0700 (PDT)
X-Originating-IP: [2607:fb90:edc:3352:8e6:5540:d1b6:c386]
Received: by 10.55.104.18 with HTTP; Tue, 13 Sep 2016 12:28:49 -0700 (PDT)
In-Reply-To: <CAJU8_nXSqSr4TjdObi5Px-gDr77hV6g6Hj5jZ45D=SnvfseC-Q@mail.gmail.com>
References: <CAB20dTt23w5oJX+i7kM1g5db=q33Af+51AH5Z0xnnptpyX90jw@mail.gmail.com> <1E1A7A63-5A74-416F-883C-665F15F176CD@sn3rd.com> <CACz1E9owJzNx9hejL4spcoBqENjoeHwd4YpLM0CtmvQVjoL5qA@mail.gmail.com> <CAJU8_nXoCozoGOzYKBLXAcYEUOuXBzyTP1xXzimDkKTB9B0dxQ@mail.gmail.com> <CAJU8_nXSqSr4TjdObi5Px-gDr77hV6g6Hj5jZ45D=SnvfseC-Q@mail.gmail.com>
From: Kyle Rose <krose@krose.org>
Date: Tue, 13 Sep 2016 15:28:49 -0400
Message-ID: <CAJU8_nVF_BSnJNS2j9D951HZVvM5FGE4=s9hLLn5RtmMFdLQ_A@mail.gmail.com>
To: William Whyte <wwhyte@securityinnovation.com>
Content-Type: multipart/alternative; boundary=001a1142d3704f83da053c689f43
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/66iyPCe-pMecNnY-JkaC33bygbY>
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 19:28:57 -0000

To be honest, the purist in me likes the general idea here, though I think
I prefer "kex" as I'm used to that with SSH.

Then again, that isn't even quite correct, as the most popular mechanism is
DH, which is key agreement based on the exchange of inputs to a formula: no
keys are actually exchanged.

I fear we're bike shedding with this proposal. Across all of computing,
there are plenty of mechanisms that appear to be misnamed for the same
reason: unforeseen but reasonable extension beyond their
originally-intended applications.

The actual name in TLS is "10", so as long as we all agree on that and
understand the history behind "supported_groups", I'm not sure it matters.

Kyle

On Sep 13, 2016 2:27 PM, "William Whyte" <wwhyte@securityinnovation.com>;
wrote:

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/15126cf5a08c445aeed97
> c0c25c4f10c2c1b8f26/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
>


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls