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

From: Sean Turner <[email-masked]>
Date: Tue, 13 Sep 2016 13:19:51 -0400

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: William Whyte <[email-masked]>
Date: Tue, 13 Sep 2016 14:27:09 -0400

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 <[email-masked]> wrote:

> 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
>
> > [1] https://github.com/ekr/tls13-spec/blob/
> 15126cf5a08c445aeed97c0c25c4f10c2c1b8f26/draft-ietf-tls-tls13.md
> >
> >
> >
> > Thanks for your time.
> >
> >
> >
> > Zhenfei Zhang
> >

---

From: Kyle Rose <[email-masked]>
Date: Tue, 13 Sep 2016 15:28:49 -0400

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" <[email-masked]>
wrote:

Cheers,

William

On Tue, Sep 13, 2016 at 1:19 PM, Sean Turner <[email-masked]> wrote:

> > [1] https://github.com/ekr/tls13-spec/blob/15126cf5a08c445aeed97
> c0c25c4f10c2c1b8f26/draft-ietf-tls-tls13.md
> >
> >
> >
> > Thanks for your time.
> >
> >
> >
> > Zhenfei Zhang
> >