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" <wwh...@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 <s...@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 <zzh...@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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
