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.) >> 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.) >> The cookie is not sent encrypted in the HelloRetryRequest since the >> HelloRetryRequest is sent when the client has not provided a suitable >> "key_share" value. The DoS protection feature used in the >> HelloRetryRequest is most likely useful only in context of an unreliable >> transport protocol. If you want DoS protection then the server should >> not store per-session state, which establishing security context would >> require. > > The "encrypted" seems to be leftover from time when there were inter- > connection cookies (which were removed). Yep, this needs to be Client* with a note that it appears in the HelloRetryRequest (a category in which this is currently the only resident). _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
