Re: [TLS] Refactoring the negotiation syntax

[Eric Rescorla <[e-mail]>]

On Wed, Jul 13, 2016 at 11:01 AM, Dave Garrett <[e-mail]>
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
>