The known_configuration mechanism in the current draft allows the
client to resurrect the handshake parameters (though not the keys)
which were negotiated in a previous handshake, but this is done
implicitly, i.e., the server provides a label and the client returns
it on the next connection. This has the advantage of keeping things
short but the disadvantage the it means that you can't have a static
configuration ID for everyone (instead, the server has to somehow
embed the properties in the configuration ID). After some thought,
I think this is a bad plan.
Here's what I propose (and what's in my slides for today):
- The client indicates configuration ID and cryptographic configuration,
including the cipher suites and cryptographic extensions. This
MUST replicate the server's selection from a previous handshake
- The server verifies the client's ClientHello and
(a) Checks that configuration ID is valid
(b) Verifies that client's parameters are what it would negotiate
Accordingly, this would change the extension to something like:
struct {
select (Role) {
case client:
opaque identifier<0..2^16-1>;
CipherSuite cipher_suite; // NEW
Extension extensions<0..2^16-1>; // NEW
case server:
struct {};
}
} KnownConfigurationExtension
The server would just need one configuration for each public key and
woudldn't need to have any client-specific state. It also has the
benefit that it makes PSK work with 0-RTT.
Thoughts? Improvements?
-Ekr
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
