On Thu, Nov 26, 2015 at 4:59 PM, Xuelei Fan <[email protected]> wrote:
> If empty key_share vector is used to indicate to request a server choice, > That's not what it means. It means "I have no idea what your preferences are, so tell me which of the groups I support you prefer". Thus, you still need supported_groups to indicate the groups you support. -Ekr I think it is not necessary to have "supported_groups" extension as > mandatory any more. key_share extension can be used for the supported > named groups. "supported_groups" extension can be used for backward > compatibility (if TLS 1.2 fade out in the future, need no "supported_groups" > extension any more). > > Or, if both are needed as mandatory, may be better to separate functions > that "supported_groups" extension defines the supported named groups and > preference, and key_share defines the shares only (no supported groups, no > preference, the groups must be defined in "supported_groups" extension). > > Xuelei > > On Fri, Nov 27, 2015 at 7:47 AM, Eric Rescorla <[email protected]> wrote: > >> >> >> On Thu, Nov 26, 2015 at 3:36 PM, Dave Garrett <[email protected]> >> wrote: >> >>> On Thursday, November 26, 2015 06:02:09 pm Eric Rescorla wrote: >>> > On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett <[email protected]> >>> > wrote: >>> > > On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote: >>> > > > I actually looked at the Editors's Copy. The description is a >>> mess: It >>> > > > seemingly first requires key_share extension, even for the first >>> > > > ClientHello... Now, that extension can't be empty... And then >>> proceeds >>> > > > to say to omit it if client has no shares to send... Which looks >>> like >>> > > > it is mutually contradictionary. >>> > > >>> > > We went back and forth on whether to omit or require an empty >>> extension. >>> > > It looks like we have a mix of the two left in there that need >>> fixing. (I >>> > > think something got merged weird) Thanks for pointing this out. >>> > > >>> > > I think it might be easier if we just required the extension for all >>> cases >>> > > where (EC)DHE suites are offered, and have it empty to request a >>> server >>> > > choice, instead of an omitted extension. >>> > >>> > Yes, we should either have that or have empty be forbidden. It's a >>> matter of taste >>> > but on balance, let's go with "empty". If you want to submit a PR that >>> cleans >>> > this up, I'll merge that. >>> >>> -> https://github.com/tlswg/tls13-spec/pull/349 >>> >>> There's one last decision, though: does "empty" mean empty client_shares >>> vector or empty "extension_data" to save 2 bytes? I think it's cleaner to >>> just keep the same extension structure for all cases and have an empty >>> shares vector, which is what I have in the current PR. >> >> >> Empty vector seems dominant. >> >> -Ekr >> >> >>> >>> Dave >>> >> >> >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
