On Fri, Aug 12, 2016 at 04:39:51PM +1000, Martin Thomson wrote: > On 12 August 2016 at 05:09, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > > Actually, the server_name could be made into 'client', since the only > > thing server sends about server_name is an ACK, meaning it has taken it > > into "consideration" (in some vague way). > > I disagree. If it can be encrypted, then it should be. (I don't > believe that we ack this in NSS, so it's moot there.)
Well, I was more like "do we need this at all?". > >> The max_fragment_length extension is sent in the initial ClientHello but > >> is not as essential as the server_name extension. Still, in most cases > >> there is no security context established at the time of sending the > >> ClientHello (at least not in the full handshake when ECDHE is used). > > > > I think max_fragement_length should be made into 'clear', given what > > it is used for. > > I disagree. The client doesn't need to use this value until it has > read all of the server's first flight, so it can be encrypted. The > server can still act on the client's value until that time. (I know > that you might make an argument that it could appear in > HelloRetryRequest to force the client to cut its second ClientHello > smaller, but that's really tricky to get right, and I think that > servers should just be prepared to swallow an entire ClientHello.) Actually, the client can just abort if it observes server generating larger fragments than it requested, so it doesn't really need the ACK for anything (and if it could handle full 16k fragments, it presumably wouldn't use the extension). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
