Re: [TLS] TLS ExtensionType Registry

[Ilari Liusvaara <[e-mail]>]

On Thu, Aug 11, 2016 at 08:56:25PM +0200, Hannes Tschofenig wrote:
> Hi Ekr, Hi all,
> 
> reading through https://tools.ietf.org/html/draft-ietf-tls-tls13-14 I
> noticed the TLS ExtensionType Registry on page 77 & page 78.
> 
> The "TLS 1.3" column has one of four values, namely
> 
>    - "Client", indicating that the server shall not send them.
>    - "Clear", indicating that they shall be in the ServerHello.
>    - "Encrypted", indicating that they shall be
>      in the EncryptedExtensions block
>    - "No" indicating that they are not used in TLS 1.3.
> 
> The following values deserve a closer look:
> 
>    +-------------------------------+-----------+-----------------------+
>    | Extension                     | Recommend |               TLS 1.3 |
>    |                               |        ed |                       |
>    +-------------------------------+-----------+-----------------------+
>    | server_name [RFC6066]         |       Yes |             Encrypted |
>    |                               |           |                       |
>    | max_fragment_length [RFC6066] |       Yes |             Encrypted |
>    |                               |           |                       |
>    | key_share [[this document]]   |       Yes |                 Clear |
>    |                               |           |                       |
>    | pre_shared_key [[this         |       Yes |                 Clear |
>    | document]]                    |           |                       |
>    |                               |           |                       |
>    | cookie [[this document]]      |       Yes | Encrypted/HelloRetryR |
>    |                               |           |                equest |
>    +-------------------------------+-----------+-----------------------+
> 
> The server_name extension is sent in the initial ClientHello and will
> not be encrypted since it will be used to select the right server in a
> hosting environment.

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).

> 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.
 
> 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).
 
> I fear that the use of extension in the encrypted block may be dependent
> on where they can first be used and also in what handshake variant. It
> is also a question whether it makes sense to send an extension encrypted
> in the ServerHello when it first appeared in clear in the ClientHello.

 
> I wonder whether the "TLS 1.3" column in this table could actually be
> simplified to only provide information about extensions that can be used
> in TLS 1.3. Whether something is sent in clear, encrypted or only be the
> client is something that should be described in the protocol
> specification itself.

Actually, in that wide sense, all extensions can be used. TLS 1.3
just forbids negotiation of some extensions. But it does not forbid
client sending any extension if downnegotiation is supported.


-Ilari