On Sat, Jul 18, 2015 at 09:22:12PM -0400, Dave Garrett wrote:
> 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.
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
> 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.
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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
