On Friday 27 November 2015 20:33:46 Xuelei Fan wrote: > On Fri, Nov 27, 2015 at 8:12 PM, Hubert Kario <hka...@redhat.com> 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
