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