I like this work, but I don't believe this to be ready yet. S1 None of the current proposed extensions are such that the server indicates support without the client first indicating support. So as not to preclude future extensions that are so defined, this specification allows the client to send an empty extension, indicating support for TLS flags in general (and presumably some unspecified features in particular).
First, for clarification, the distinction between empty and all-zero-valued is perhaps worth drawing on. Second, more seriously, if this is the goal, the text needs to acknowledge that the possibility exists on a *per-flag* basis. Third, more substantially, and invalidating the above, I don't think that we should make flags introduce a new style of negotiation just because it can. I would strongly prefer that this function as close as possible to "empty ClientHello extension; empty EncryptedExtensions extension". Aside from that, the utility of an advertisement from the server that a client cannot respond to is pretty marginal. Fourth, this conflicts with the following text in S2: A server that supports this extension and also supports at least one of the flag-type features that use this extension and that were declared by the ClientHello extension SHALL send this extension with the intersection of the flags it supports with the flags declared by the client. Nit here: this isn't about support alone, it is the flags that the server *chooses* to support. S2 The server may need to send two tls_flags extensions, one in the ServerHello and the other in the EncryptedExtensions message. Are we confident that sending the same extension in both places is safe? I know that clients have to implement this and so should be able to test that this works, but it seems awkward. And it might not be necessary. It's also not sufficient, as we currently allow responses to ClientHello extensions to appear in Certificate (and for CertificateRequest to carry "requests" in the other direction). Perhaps we might avoid this problem entirely. ServerHello extensions are limited to key exchange. If we say that flags are limited (today) to functional properties that don't affect key exchange, my thought is that we don't lose much (if anything) by only allowing this extension in EncryptedExtensions. I don't know what I think about Certificate extensions. This seems to have a clear use there. Editorial: S1 It might be better to draw examples from the canon of published RFCs than to refer to things that might not get published. On Tue, Apr 7, 2020, at 00:53, Christopher Wood wrote: > This is the working group last call for the "A Flags Extension for TLS > 1.3" draft, available at: > > https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ > > Please review the document and send your comments to the list by April > 20, 2020. The GitHub repository for this draft is available at: > > https://github.com/tlswg/tls-flags > > Thanks, > Chris, on behalf of the chairs > > _______________________________________________ > 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
