Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3

[Dave Garrett <[e-mail]>]

On Thursday, November 26, 2015 08:28:35 pm Xuelei Fan wrote:
> If  "supported_groups" extension is only for compatibility, it can be
> not-mandatory.  However, if it is defined to define the supported groups
> and preferences (see bellow), it can be mandatory.

If it weren't for the fact that we're retrofitting the elliptic_curves extension from RFC 4492 into the supported_groups extension via draft-ietf-tls-negotiated-ff-dhe & the TLS 1.3 draft, then yes, we'd probably have the key sharing and group support enumeration in the same extension. We are recycling the old extension for backwards compatibility, however, so we're having these two things be separate. A 20 year old protocol is just going to have kludgey stuff like this, whether we like it or not. ;)

> In section 6.3.2.3:
>     client_shares
>          A list of offered KeyShareEntry values in descending order of
> client preference.
> 
> I think, key_share is ordered too.  If considering both key_share and
> supported_groups together, looks like there are two options
[...]

Yes, I addressed the conflict of priorities in one of my PRs, but it's on my todo list to rewrite it as ekr noted a few parts that needed changing. We agreed on simply making the two orders be required to be the same, though at "SHOULD"-level requirement. Those that have them differ will be dealt with at the implementations' discretion.

> For this case, key_share can be omitted to indicate to request server
> choice shares.

I dislike special cases; people screw them up. Life is easier if all (EC)DHE suites need a fixed set of accompanying extensions. Less complicated and simpler to describe clearly. (as pointed out, omitting it left us with garbled text, though that was also just due to us flip-flopping on how to handle it)


Dave