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

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
>