On Fri, Nov 27, 2015 at 9:28 PM, Hubert Kario <hka...@redhat.com> wrote:
> 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 > > As the check needs additional effort, and the client code also needs additional effort to keep the order consistent, I think the logic may be more complex. Anyway, not a big concern to me. Personally, I prefer one logic one place. > > If the orders are not consistent, if I can choose from two options: > > continue or alter, I would choose the continue option. > > alter what? > > If the preference orders in key_share and supported_groups are not consistent, I think an alert message is expected. > > 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. > > Sure, if both peer strict follow the spec. But implementation may be not correct. Conner case, of course. Thanks & Regards, Xuelei
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
