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

From: "Christopher Wood" <[email-masked]>
Date: Mon, 06 Apr 2020 07:53:25 -0700

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

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 6 Apr 2020 15:21:00 +0000

I re-read it.  Ship it.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 07 Apr 2020 08:39:06 +1000

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:
> Please review the document and send your comments to the list by April 
> 20, 2020. The GitHub repository for this draft is available at:
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 21 Apr 2020 05:53:41 -0700

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,

On Mon, Apr 6, 2020, at 3:39 PM, Martin Thomson wrote:
> 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.
> 
> 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.
> 
> It might be better to draw examples from the canon of published RFCs 
> than to refer to things that might not get published.
>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 21 Apr 2020 22:31:41 +0300

Inline...

> On 7 Apr 2020, at 1:39, Martin Thomson <[email-masked]> wrote:
> 
> First, for clarification, the distinction between empty and all-zero-valued is perhaps worth drawing on.

I think the description of the extension in section 2 is clear. An extension without any flags set is empty, It’s not all zero-valued.  A FlagsExtensions field with a length of 1 and the one byte being zero is an invalid encoding of the extension as its length is the minimal length possible. So only an empty extension is meaningful.

>  Second, more seriously, if this is the goal, the text needs to acknowledge that the possibility exists on a *per-flag* basis.

Can you suggest text?

> 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…

If this is what the group prefers, I’m fine with it, but then there’s never any point in sending an empty extension, either from the client of form the server. The absence of an individual flag is always implied from the absence of the extension.

>   the intersection of the flags it supports with the flags declared by

Agree. So either we abolish “silent client - server declares” extensions (let’s call them unsolicited), or we rephrase the above something along the lines of:

    A server that supports the extension and also supports at least one flag that was either present in the ClientHello extension or is allowed to be sent unsolicited, SHALL send this extension with all of the flags it is configured to support except those that are not allowed to be sent unsolicited and that were not present in the ClientHello extension

> Nit here: this isn't about support alone, it is the flags that the server *chooses* to support.

“configured to support” ?

> 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 mig…

I don’t think the two extensions ever carry the same flags. Each server side flag should be one of three: serverHello, encrpytedExtensions, or neither (if we are not expecting a response)

I think this requires another field in the IANA registry.

As for Certificate, I don’t see why we’d need to add bit responses to Certificate. They can safely be sent in either serverHello or encryptedExtensions.

> 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,…

I’m trying to come up with key exchange bits that might be useful.  Perhaps a new, improved alternative to HKDF?  Support for Quantum Key Exchange?

> It might be better to draw examples from the canon of published RFCs than to refer to things that might not get published.

I support I cna mention RI earlier.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 23 Apr 2020 10:07:40 +1000

On Wed, Apr 22, 2020, at 05:31, Yoav Nir wrote:
> If this is what the group prefers, I’m fine with it, but then there’s 
> never any point in sending an empty extension, either from the client 
> of form the server. The absence of an individual flag is always implied 
> from the absence of the extension.

When you say "empty extension" here, do you mean "empty flags extension" or are you speaking more generally?

If the server can't add flags, then I agree that having the client send an empty flags extension has little value.  Same for the server sending an empty flags extension in that case.
 
> I don’t think the two extensions ever carry the same flags. Each server 
> side flag should be one of three: serverHello, encrpytedExtensions, or 
> neither (if we are not expecting a response)

So the intersection of flags in different responses must be zero?  i.e. flags[ServerHello] & flags[EncryptedExtensions] == 0 (and the same for any combination that we allow, including Certificate and NewSessionTicket, I guess).
 
> As for Certificate, I don’t see why we’d need to add bit responses to 
> Certificate. They can safely be sent in either serverHello or 
> encryptedExtensions.

The obvious thing here is when the extension applies on a per-certificate basis as opposed to the entire chain.  But I don't have an example you can use; see below.

> I’m trying to come up with key exchange bits that might be useful.  
> Perhaps a new, improved alternative to HKDF?  Support for Quantum Key 
> Exchange?

This might require an understanding of the overall strategy.  If the goal is to provide an analogue of a generic "empty extension", then sure, put it in ServerHello.  But put it in Certificate and NewSessionTicket too.  But if you make this more narrowly applicable and say that you have a different flags extension for each type of exchange (ClientHello -> ServerHello, ClientHello -> EncryptedExtensions, ClientHello -> NewSessionTicket, ClientHello/CertificateRequest -> Certificate), then you might avoid answering this question for now.

Right now, it seems like the obvious use here is for EncryptedExtensions, so we could decide to defer that architectural question by saying that it is limited to EncryptedExtensions for now.  Then we can either expand the one flags extensions to allow it in NewSessionTicket when we need to, or define a new one.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 25 Apr 2020 21:38:23 +0300

See below.

I think the next thing to do is to get a signal from the working group about whether we do or don’t want to allow unsolicited server flags, because prohibiting it will require a significant change in the draft.

I’m happy to make such a change, because I still can’t come up with such a flag.

> On 23 Apr 2020, at 3:07, Martin Thomson <[email-masked]> wrote:
> 

I mean the flags extension. An empty extension conveys just that the sender supports the extension. An empty CH flags extension just says the client supports the flags extension. Unless the server is allowed to send unsolicited flags, an empty flags extension in CH does not convey any useful information.
> So the intersection of flags in different responses must be zero?  i.e. flags[ServerHello] & flags[EncryptedExtensions] == 0 (and the same for any combination that we allow, including Certificate a…

I can’t think of any flag that will have a different meaning when sent in SH or EE so that you might want to send both. Just in case, the flag registry should have a field similar to the extension registry which says where the field is valid.