On Sat, Apr 25, 2020, at 11:38 AM, Yoav Nir wrote: > 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.
Given that it's a deviation from the norm, and we don't have a compelling use case, I think we ought to make the change. If you have cycles, would you be willing to draft that change for review? > > On 23 Apr 2020, at 3:07, Martin Thomson <m...@lowentropy.net> wrote: > > > > On Wed, Apr 22, 2020, at 05:31, Yoav Nir wrote: > >>> 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. > >> > >> 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 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. > > > >>> 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). > >> > >> 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). > > 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. That seems reasonable, though I think restricting the flags to EE is probably better. The possible cases for inclusion in SH (another KEX or KDF algorithm?) seem like they can be handled by existing client extensions. Best, Chris (no hat) _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
