Thanks for the context, everyone! Based on that, PR looks good to me. Ship it!
David On Tue, Jun 30, 2020 at 9:18 PM Martin Thomson <m...@lowentropy.net> wrote: > More to the point, this makes it more difficult to analyze relative to an > empty "flag" extension of the likes we currently use. > > I haven't implemented this, but I imagine one strategy would be to rewrite > these flags and pretend that they were empty extensions. That would allow > implementations to reuse a lot of infrastructure, like the stuff we added > for custom extensions. That would be more difficult if the server can > speak first. > > On Wed, Jul 1, 2020, at 14:03, Yoav Nir wrote: > > Yeah, the thread that Nick mentioned. > > > > Also, since there are no such extensions defined in the base TLS 1.3 > > spec, the server can’t assume that the client knows what either the > > specific flag means, or the entire flags extension means. > > > > So suppose we invent some new client authentication scheme for TLS, it > > does make sense for the server to signal that it supports this so that > > the client can do. But I don’t think it’s too onerous to require that > > the client indicate support first. > > > > Yoav > > > > > On 1 Jul 2020, at 2:30, David Schinazi <dschinazi.i...@gmail.com> > wrote: > > > > > > Hi Yoav, > > > > > > Could you elaborate on the rationale for this change please? > > > I was assuming that the ability for servers to send extensions not > requested by clients was useful. > > > > > > Thanks, > > > David > > > > > > On Mon, Jun 29, 2020 at 2:34 PM Yoav Nir <ynir.i...@gmail.com> wrote: > > >> Hi > > >> > > >> I’ve just submitted the following PR: > > >> > > >> https://github.com/tlswg/tls-flags/pull/4 > > >> > > >> Three changes: > > >> * It is no longer allowed to send an empty flags extension. If you > don’t support any flags, don’t send the extension. > > >> * The server is no longer allowed to respond with flag types that > the client didn’t indicate support for first. > > >> * I’ve split the extension description section into a format section > and a rules section > > >> > > >> Please comment. Barring any objections, I’ll merge the PR just before > the submission deadline. > > >> > > >> Yoav > > >> > > >> _______________________________________________ > > >> TLS mailing list > > >> TLS@ietf.org > > >> https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
