RFR: 8326643: JDK server does not send a dummy change_cipher_spec record after HelloRetryRequest message [v5]

[Sibabrata Sahoo]

On Thu, 21 Mar 2024 02:10:35 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/TLSv13/EngineOutOfSeqCCS.java line 98:
>> 
>>> 96: 
>>> 97:             // client consumes ServerHello/HelloRetryRequest
>>> 98:             clientResult = clientEngine.unwrap(sTOc, clientIn);
>> 
>> May be it would be nice to ensure it really received a HRR record when isHRRTest=true by checking the Handshake record attribute content Random=“cf21ad74e59a6111be1d8c021e65b891c2a211167abb8c5e079e09e2c8a8339c” which is SHA-256("HelloRetryRequest")
>
> Great suggestion. According to the RFC, in middlebox compatibility mode, the Server should send CCS for all the first handshake messages. Currently, those include HRR and SH. I don't think it's wise to validate all the first handshake messages from the Server in this test.

I think it would be nice to have. Here is the reason,
The Test has 2 cases. 
First, generate HRR because it set "secp384r1" as NamedGroup which makes client guess wrong and in-turn the server send HRR.
Second, generate SH because client guess of NamedGroup is correct.

What if "secp384r1" added to default NamedGroup tomorrow. In that case both Test case will be executing Second case. i.e. SH will always sent for both cases and the HRR will never sent. As the test will always pass for that change no-one will care to correct the case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18372#discussion_r1533260753