Subject: [TLS] TLS ExtensionType Registry

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 11 Aug 2016 20:56:25 +0200

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.

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

The key_share & the pre_shared_key extension is sent in clear in the
ClientHello and in the ServerHello.

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.

I believe the definition of 'clear' should be changed to:

    "Clear", indicating that they shall be sent in clear
    in the ClientHello and in the ServerHello.

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.

Ciao
Hannes

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 11 Aug 2016 22:09:29 +0300

> The following values deserve a closer look:

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

> 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.
 
> not store per-session state, which establishing security context would

The "encrypted" seems to be leftover from time when there were inter-
connection cookies (which were removed).

> client is something that should be described in the protocol

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Aug 2016 16:39:51 +1000

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

> I think max_fragement_length should be made into 'clear', given what

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

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 12 Aug 2016 12:02:32 +0300

> believe that we ack this in NSS, so it's moot there.)

Well, I was more like "do we need this at all?".

> 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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Aug 2016 19:47:15 +1000

> Well, I was more like "do we need this at all?".

Yep, there is that :)