[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] WGLC for "A Flags Extension for TLS 1.3"
From:       "Christopher Wood" <caw () heapingbits ! net>
Date:       2020-06-01 20:15:37
Message-ID: 630127d8-3423-4afc-808a-e61165a76a26 () www ! fastmail ! com
[Download RAW message or body]

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 <mt@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


[prev in list] [next in list] [prev in thread] [next in thread]