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

[Xuelei Fan <[e-mail]>]

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

> On Friday 27 November 2015 21:20:24 Xuelei Fan wrote:
> > > > > 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 means that the code needs to keep references to two arrays at
> > > the same time and either create a hash table for lookups in key
> > > shares or iterate over key shares for every try - this makes code
> > > and logic more complex, not less
> >
> > I did not get the idea, can the complex above be avoided if keeping
> > both? Does one preference order just get ignored?
>
> the idea is that if there is a key share acceptable for the server, the
> supported_groups can be ignored
>
> but to make sure that clients don't start putting complete garbage
> there, we need to tell servers to check key shares against
> supported_groups
>
> As the check needs additional effort,  and the client code also needs
additional effort to keep the order consistent, I think the logic may be
more complex.

Anyway, not a big concern to me.  Personally, I prefer one logic one place.


> > If the orders are not consistent, if I can choose from two options:
> > continue or alter, I would choose the continue option.
>
> alter what?
>
> If the preference orders in key_share and supported_groups are not
consistent, I think an alert message is expected.



> > Alert message
> > is expensive in practice.
>
> Note that this alert will never be sent to a client that is behaving
> according to specification unless the packets were modified by the
> network. It's a sanity check.
>
> Sure, if both peer strict follow the spec.  But implementation may be not
correct.  Conner case, of course.

Thanks & Regards,
Xuelei