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