On Fri, Nov 27, 2015 at 9:12 AM, Eric Rescorla <[email protected]> wrote:
> > > 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. > > Make sense to me. Thanks, Xuelei > -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
