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
