Clarification on server-side validation of second ClientHello after HelloRetryRequest

[jouho]

Hello! We are maintainers of s2n-tls, an open-source TLS implementation. We recently encountered an interoperability issue that led us to question how servers should handle the second ClientHello after a HelloRetryRequest.

RFC 8446 §4.1.2 requires that clients send the same ClientHello without modification after receiving a HelloRetryRequest, except for the explicitly allowed changes (key_share, early_data, cookie, pre_shared_key, and padding). However, the RFC does not specify whether servers should validate this consistency.

In practice, TLS implementations diverge on this:

OpenSSL and rustls do not validate CH1 vs CH2 consistency on the server side
s2n-tls and LibreSSL do validate and will reject a non-conformant second ClientHello
This divergence recently caused an interoperability issue between s2n-tls and a client (NanoSSL) that trims its cipher suites, supported groups, and supported versions in the second ClientHello: digicert/trustcore#60

The client behavior is non-compliant, but the fact that some servers accept it means client implementers may not discover the issue until they encounter a server that enforces the check.

We'd like to get the working group's perspective on a few questions:

1. Should the RFC include guidance on whether servers should (or must) validate the second ClientHello for consistency with the first?
2. If server-side validation is not required, how is a server expected to know whether it is communicating with a compliant client? Without server enforcement, the client-side MUST in §4.1.2 is effectively unverifiable.
3. For implementations that currently enforce this check, are there security implications to relaxing it?

Thank you in advance for any guidance on this.

[ekr]

As a general matter, we don't require that the receiving party enforce all MUSTs in the specification and in fact some of them are not remotely verifiable at all. For example you can't really verify that ClientHello.random and ServerHello.random are randomly generated. So, I don't think that point (2) is really an issue.

I'm not aware of any security implications to relaxing the check -- as distinct from whether there are implications from being non-conformant -- but it seems like it would be better for the ecosystem if servers checked. Barring a requirement not to validate it, I think it's reasonable for a server to either do so or not do so. I probably wouldn't be opposed to requiring or at least encouraging them to do so as a general matter, but this late in the process I think you'd need a good reason and in any case you'd need to bring it to the list.