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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
