This WGLC is now complete. We need more reviews, and likely a bit more work, before moving this ahead. We'll run another WGLC once we have both.
Yoav, can you please have a look at the comments and concerns raised below and address them as needed? Thanks, Chris, on behalf of the chairs On Mon, Apr 6, 2020, at 3:39 PM, Martin Thomson wrote: > 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 > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
