davidben
commented
3 years ago Since this came up in #1223, some scenarios where things get messy:
server_name-dependent preferences
Suppose the server has different cipher suite or curve preferences based on server_name. That means it cannot make the HRR decision without looking at the server_name. Such a server must dispatch on the server_name. If it ignores or checks the second server_name, that's fine. But it cannot redispatch or risk getting itself in an inconsistent state.
psk_ke
Suppose the server implements psk_ke (please don't) and only implements X25519. Now suppose it gets the following ClientHello:
- PSK: 12345
- supported_groups: P-256, X25519
- key_share: P-256
If the server does not resume, it must HRR to request a different curve. If it does resume, it must not request a second curve. That means the server must make and commit to the resumption decision on the first ClientHello.
ClientHello inspection
Suppose the server is stateful and offers the application a chance to inspect the ClientHello and reconfigure the connection. There is an implicit promise to the application: the ClientHello you saw is the one that will be used. Such a server then has two choices:
- Make all decisions on the first ClientHello. The second ClientHello is merely an inefficient ClientKeyExchange.
- Tell both ClientHellos to the application and hope it figures it out. This is fragile since HRRs are rare, so applications may not handle it. It also may is not backwards-compatible if the API predates TLS 1.3.
PSK binders
Suppose the server makes most decisions on the first ClientHello. Must it still re-check the second PSK binder? Probably, but I don't think we ever wrote it down anywhere.
Stateless
Suppose the server is stateless. Now some things are reversed and others aren't. The ClientHello inspection issue now points to option (2) because a truly stateless HRR API will interpret the two ClientHellos as independent connections. Moreover, making decisions on or even looking at the first ClientHello is tricky because they must be pickled into the HRR cookie.)
At the same time, the protocol considerations still apply, so some decisions must be made on the first ClientHello. Those must be recomputed and rechecked on the second ClientHello. Note even a strict ClientHello consistency check is insufficient for a stateless server because a stateless server may have changed its configuration between the two connections.
The specification doesn't go into any of this, so we're left with a wide space of HRR handling, some of which are more risky than others. I think we should decide more clearly what the HRR rules are and offer more concrete guidance here. (And then redo this for TLS 1.4 because I think this design was clearly too complex to manage. :-) )
ekr
There's probably room here to describe HRR server behavior more specifically. Although the client is required to align the first and second ClientHello (see https://github.com/tlswg/tls13-spec/issues/1223), there is no text saying how the server. Even so, depending on how the server implements HRR, it may need to check some subset of consistency between the two.
When you make each decision is also tricky. Do you look at the first ClientHello? The second? Both, checking that you came to the right answer? Which binders do you check? Depending on implementation properties (stateful vs. stateless, APIs to allow the caller to inspect the ClientHello, psk_ke linking the PSK and key_share decisions together, etc.), you may need to pick different options here.
This is probably worth some text to describe the space of valid implementation decisions.