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

[Dave Garrett <[e-mail]>]

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