On Wed, Jul 13, 2016 at 11:01 AM, Dave Garrett <davemgarr...@gmail.com> wrote:
> 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. I don't think it affects it either way. 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. David suggested this offline, but I don't think this makes things significantly simpler, because now. 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. > I think this actually makes matters *worse* because then you have one situation where (ECDHE) where the server sends one key share and one (ECDHE-PSK) where the server has to send/acknowledge two -Ekr 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
