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

[Hubert Kario <[e-mail]>]

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

> If the orders are not consistent, if I can choose from two options:
> continue or alter, I would choose the continue option.

alter what?

> 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.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic