Re: [TLS] WGLC for "A Flags Extension for TLS 1.3"

[Christopher Wood <[e-mail]>]

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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
> >
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>