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 > <mailto:ynir.i...@gmail.com>> wrote: > Hi > > I’ve just submitted the following PR: > > https://github.com/tlswg/tls-flags/pull/4 > <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 <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
