Subject: [TLS] Does the ServerHello really need unencrypted extensions at all?

From: Dave Garrett <[email-masked]>
Date: Sat, 18 Jul 2015 21:22:12 -0400

There's two issues (basically duplicates) for this topic, as well as an inline TODO.
https://github.com/tlswg/tls13-spec/issues/66
https://github.com/tlswg/tls13-spec/issues/72
https://tlswg.github.io/tls13-spec/#server-hello

The current expectation is to separate extensions into unencrypted and encrypted, with:
"The ServerHello MUST only include extensions which are required to establish the cryptographic context."

The rest then go into the new EncryptedExtensions message.

Are there really any extensions that this applies to? What extension couldn't we get away with encrypting? As soon as ServerKeyShare is sent, the client should have enough information to decrypt the encrypted extensions message.

Site note: ServerKeyShare could probably just be merged into ServerHello at this point:

   struct {
       ProtocolVersion server_version;
       Random random;
       CipherSuite cipher_suite;
       select (DH) {
           case true:
               NamedGroup group;
               opaque key_exchange<1..2^16-1>;
           case false:
               struct {};
       };
   } ServerHello;

Even if an extension is desired to set up a cryptographic context, then ideally you'd want to set up a basic extension-less one _first_, send an encrypted extensions message containing that needed extension, then send a second encrypted extensions message using the new context using the extension. The goal is to encrypt all the things, per TLS WG charter, so I don't see a point in allowing unencrypted extensions in ServerHellos at all anymore.

Is there some reason why such a plan wouldn't be able to work? Having two places to put server extensions is bound to cause mistakes.

Dave

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 19 Jul 2015 11:02:21 +0300

On Sat, Jul 18, 2015 at 09:22:12PM -0400, Dave Garrett wrote:
> Are there really any extensions that this applies to? What extension
> couldn't we get away with encrypting? As soon as ServerKeyShare is sent,
> the client should have enough information to decrypt the encrypted
> extensions message.

Going through extension list, I think the following need to go to
ServerHello (and aren't considered deprecated):

max_fragment_length (existing, IIRC, a single enumeration)
known_configuration (new in TLS 1.3, just an ACK flag)
pre_shared_key (new in TLS 1.3, PSK only, 1 octet string)
early_data(?) (new in TLS 1.3, just an ACK flag)

(Technically known_configuration and early_data could be pushed
further, but that would create annoying special cases).

Additionally, if the handshake shape is to be fixed by CH/SH,
the following need to go to SH, because these introduce or change
messages (post EE, so with variable shape, EE is possible):

client_certificate_url
status_request
user_mapping
client_authz
server_authz
status_request_v2
signed_certificate_timestamp

> Even if an extension is desired to set up a cryptographic context,
> then ideally you'd want to set up a basic extension-less one _first_,
> send an encrypted extensions message containing that needed extension,
> then send a second encrypted extensions message using the new context
> using the extension. The goal is to encrypt all the things, per TLS WG
> charter, so I don't see a point in allowing unencrypted extensions in
> ServerHellos at all anymore.

Changing ServerHello has the problem of then having incompatible
message with the same message type (the only offender for this currently
is IIRC ServerConfig, which collides with TLS 1.2 ServerHelloDone).

Additionally, if you ever need a security fix extension (:vomit:), those
likely would have to go to ServerHello.

-Ilari

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 20 Jul 2015 09:02:18 +0200

On Sat, 2015-07-18 at 21:22 -0400, Dave Garrett wrote:
> Are there really any extensions that this applies to?

The extensions which indicate the type of server (ALPN) or the name of
server must be able to be sent in the clear. The reason is that middle
-boxes or proxies must be able to determine the actual server to
transfer the session without terminating it.

regards,
Nikos