On Fri, Jan 22, 2021, at 16:16, Yoav Nir wrote:
> See this PR: https://github.com/tlswg/tls-flags/pull/5

It looks like there is lots of disagreement there.  I'm going to disagree with 
others too.

> All except the first are Server-side.

Certificate is client-side too.

> The controversy is about unsolicited flags. An unsolicited flag is a 
> flag that is set in a Flags extension in a server-side message without 
> having been first declared in the ClientHello extension.

So I think that you need to separate requests from responses.  Because 
Certificate contains response to ClientHello or CertificateRequest, my view is 
that CertificateRequest can contain any flag (provided that the definition of 
that flag permits it or you don't know whether it does) and Certificate can 
only contain flags that CertificateRequest did.  

This is part of what Ekr seems to have objected to, and I agree with him there. 
 A server should be able to use any flag in NewSessionTicket or 
CertificateRequest because those are the messages that initiate an exchange 
(NST doesn't generate any response, so it's an exchange with one flight, but 
that's immaterial).

To review:
ClientHello is answered by HelloRetryRequest, ServerHello, EncryptedExtensions, 
and (server) Certificate.
CertificateRequest is answered by (client) Certificate.
NewSessionTicket is not answered (which is totally fine).

Those three first messages above can include new flags.  They can contain the 
extension or not at the discretion of the entity that sends the message.  Those 
messages that are in response can only contain the extension if the initiating 
message contained the extension.  Furthermore, the extension can only contain a 
specific flag if the initiating message contained that flag.

In other words, each flag is treated just like an empty extension: you can 
initiate an exchange with it, but you can only answer with it if it was 
initiated with it.

This differs a little from Chris who suggests that only NewSessionTicket can 
include a flag that was previously not indicated.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to