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

[Hubert Kario <[e-mail]>]

On Friday 27 November 2015 20:33:46 Xuelei Fan wrote:
> 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.
>
> > 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

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

not the first, and certainly not the last checks that need to be done to 
implement TLS securely...
-- 
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