Re: [TLS] TLS ExtensionType Registry

[Martin Thomson <[e-mail]>]

On 12 August 2016 at 05:09, Ilari Liusvaara <[e-mail]> 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).