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. > 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, it would be better to 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. > > 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 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. Thanks & Regards, Xuelei
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
