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
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
