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

[Xuelei Fan <[e-mail]>]

On Fri, Nov 27, 2015 at 8:12 PM, Hubert Kario <[e-mail]> wrote:

> On Friday 27 November 2015 10:50:40 Xuelei Fan wrote:
> > > On Thursday, November 26, 2015 09:12:14 pm Xuelei Fan wrote:
> > > > Can key_share offers two shares for the same group?
> > >
> > > It's currently worded "Clients MUST NOT offer multiple KeyShareEntry
> > > values for the same parameters", which is a little ambiguous, but I
> > > interpret this as one share per group. I don't know why you'd need
> > > to offer more than one, anyway.
> > >
> > Need no more than one.  Then, it may be more simple that key_share
> > does
> > not define the preference order. The preference order is covered by
> > supported_groups.
>
> What would then be the expected behaviour of the server if the first
> group in the supported_groups does not have a associated key share?
>
> Try the next  group in the supported_groups until find an associated key
share.



> that is, I advertise support for secp384r1, secp256r1 or ffdhe2048, but
> I provide only secp256r1 key share as it's the one that's most widely
> supported
>
> Should the server ask me to provide a secp384r1 key share or should it
> just proceed with secp256r1?
>
> I think, it would be better to proceed with secp256r1.



> I think that specifying *both* in preference order, and recommending the
> servers to first inspect key shares and then supported_groups (if no
> intersect between what server supports and what key shares client
> provided) would end up with more predictable behaviour and cleaner code.
>
> But if the orders are not consistent, the logic get annoyed.  It's a good
practice to keep the order consistent, but it would be better if the
preference order is unique and specified in one place.


>
> That being said, we probably should say that clients MUST advertise
> support for all groups for which they send key shares and servers MUST
> abort connection with something like illegal_parameter if that happens
>
This adds additional checking on both client and server.  Personally, I
would prefer to use one preference order in order to avoid any order
conflict.

Thanks & Regards,
Xuelei