Closed pkelsey closed 12 months ago
It's my fault for not responding to this comment sooner, but I'm not sure what version of the document this comment refers to. Section 7.1 does have the following text:
* If sending a HelloRetryRequest, the server MAY include an "encrypted_client_hello" extension with a payload of 8 random bytes; see [Section 10.9.4](https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#dont-stick-out) for details.[¶](https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#section-7.1-13.1)
* If the server is configured with any ECHConfigs, it MUST include the "encrypted_client_hello" extension in its EncryptedExtensions with the "retry_configs" field set to one or more ECHConfig structures with up-to-date keys. Servers MAY supply multiple ECHConfig values of different versions. This allows a server to support multiple versions at once.[¶](https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#section-7.1-13.2)
The former condition is the case where the server MAY include this extension, so I think the requirement language is consistent. I'm going to close on the basis of that understanding, but please do reopen if you feel I misunderstood this issue.
In section 5, it says
However, in Section 7.1, there is no scenario where the use of this encrypted_client_hello payload is "truly optional" per RFC 2119. The intention here appears to be to describe that the server "might" do this. Fixing the wording here might be considered to overlap with #454.