Closed kr15tyk closed 3 months ago
I agreed. Ignoring the renegotiation request should be an acceptable option for TLS client.
I believe this is already being addressed by RFI 202402a.
I agree this issue was covered by RfI#202402a
Apologies for the duplicate issue. We can close this once 202402a is posted for review.
RFI 202402a/b has been posted on the CCUF Forum. Please review and provide comments at, https://www.ccusersforum.org/forums/network-itc-interpretation-team/tr2td-rfi202402a-b-separation-of-test-definitions-for-tlsv1-2-and-v1-3-renegotiation/
The Test specifies that a Hello reset request shall be sent and that the client is to close the connection once receiving this message. I believe the hello reset request correlates to a Hello Request message (RFC 5246 Section 7.4.1.1) as that is the closest described item I have found so far. The issue is that the RFC does not mandate that the client terminate the session if it does not wish to support renegotiation, as the RFC states in section 7.4.1.1 “This message MAY be ignored by client if it does not wish to renegotiate a session, or the client may, if it wishes, respond with a no_renegotiation alert.”. Thus, it seems to be the case that the NDcPP 3.0 test FCS_TLSC_EXT.1.9 Test 4 is enforcing requirements onto a client which are not enforced by RFC 5246. If I have the incorrect RFC for what is meant by hello reset request, can you point me in the correct direction for the RFC which is used to define this behavior? Otherwise, it would seem that the Test activity defined could be in a situation where a product is validly implementing RFC 5246 but is not able to pass the test as written if the product choses to just ignore hello request messages entirely.