On Wednesday, July 13, 2016 01:12:54 pm Eric Rescorla wrote: > The basic idea here is to factor out the TLS 1.3 negotiation into three > mostly orthogonal axes. > > - Symmetric cipher/PRF -- indicated by the cipher suite list as in TLS 1.2 > - Key exchange -- indicated by the key_shares and pre_shared_key extensions > - Authentication -- indicated the signature_algorithms and pre_shared_key > extensions > > A proposal for how to do this is below. See the end for other options, > caveats, etc. > > > If we take PSK out of the picture, this gives us a very simple structure: > > - The client offers a set of key_shares and the server picks one that it > likes [1]. > - The client offers a list of signature_algorithms and the server picks > a certificate/key that matches that list and signs with it.
Your proposal ignores the supported_groups extension. The requirement of this is one of the wrenches that causes the complexity of this whole system to increase. HelloRetryRequest is the other wrench here. We very much could do everything supported_groups does in key_share; just stick unsent supported groups in the share with null keys. The desire to maintain backwards compatibility with a different mechanism using the old version of supported_groups is what makes this a problem. (back compat is not free) As to the PSK side of things, one idea which I brought up at some point is to merge the PSK extension into the key share extension to create one unified key exchange extension. We just assign some group ID to PSK, then the identity is just its equivalent of a key to be in the bag of keys. One less new extension to worry about, and instead one new extension that is 100% required for all TLS 1.3 requests, without exceptions that might need to be handled. (blending into the other current list thread, here) The special handling of PSK is another one of these metaphorical wrenches that increases the design complexity in various places. As to the actual core proposal, it could work. I too am not ideally in favor of redoing everything at this late stage, but I'm not against reconsidering it, if we can all actually agree on an alternative. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
