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

[Hubert Kario <[e-mail]>]

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?

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


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