Re: [TLS] Flags extension and announcing support
Yoav, I think that’s right, i.e., update the patch branch and PR. spt > On Jan 25, 2021, at 16:04, Yoav Nir wrote: > > OK. I think we have as much consensus as we’re likely to get. > > I’ve updated the patch branch and PR to reflect this. > > Yoav > >> On 22 Jan 2021, at 7:45, Martin Thomson wrote: >> >> 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 > > ___ > 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
Re: [TLS] Flags extension and announcing support
OK. I think we have as much consensus as we’re likely to get. I’ve updated the patch branch and PR to reflect this. Yoav > On 22 Jan 2021, at 7:45, Martin Thomson wrote: > > 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Flags extension and announcing support
On Fri, Jan 22, 2021, at 1:54 AM, Nick Harper wrote: > On Thu, Jan 21, 2021 at 9:46 PM Martin Thomson wrote: > > 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. > > > I agree that this is the correct guiding principle for handling flags. > We should allow unsolicited flags in the same places we allow > unsolicited extensions. Going by section 4.2 of RFC 8446, that would be > ClientHello, CertificateRequest, and NewSessionTicket. +1 -- and thanks, Martin, for summarizing the principle so elegantly! Best, Chris ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Flags extension and announcing support
On Fri, Jan 22, 2021 at 1:55 AM Nick Harper wrote: > On Thu, Jan 21, 2021 at 9:46 PM Martin Thomson wrote: > >> 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. >> >> I agree that this is the correct guiding principle for handling flags. We > should allow unsolicited flags in the same places we allow unsolicited > extensions. Going by section 4.2 of RFC 8446, that would be ClientHello, > CertificateRequest, and NewSessionTicket. > FWIW, this is what I was trying to say as well, though I'm prepared to believe I didn't say it. There is also a separate but related question of whether you can send an unsolicited flags *extension* regardless of the contents of that extension in these messages. I believe you should be able to for the reason Nick and Martin indicates above. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Flags extension and announcing support
On Thu, Jan 21, 2021 at 9:46 PM Martin Thomson wrote: > 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. > > I agree that this is the correct guiding principle for handling flags. We should allow unsolicited flags in the same places we allow unsolicited extensions. Going by section 4.2 of RFC 8446, that would be ClientHello, CertificateRequest, and NewSessionTicket. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Flags extension and announcing support
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
