On Thu, Nov 26, 2015 at 3:36 PM, Dave Garrett <davemgarr...@gmail.com> wrote:
> On Thursday, November 26, 2015 06:02:09 pm Eric Rescorla wrote: > > On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett <davemgarr...@gmail.com> > > 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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
