Renegotiation Updates

[kenji-lightship]

Updates to address Issues/Comments:

• resolves #286 /Comment 14 - Suggested updates for comment 52 were incorporated.
• resolves #286 /Comment 15 - The intro to the Optional DTLS requirements was edited. I think the confusion came from old examples that have lost value as other updates were made, so the examples were deleted.
• resolves #287 /Comments 18 and 21 - no longer applicable due to the comment 14 and 52 updates.
• resolves #306 /Comment 52 - suggestions from the email were incorporated with a few updates for clarity.

Note: SD paragraph numbers were not updated. I assume that is a task we can handle with a script once all the edits are complete.

[kenji-lightship]

Based on RFC 5746 Section 3.2, the renegotiation_info in the ClientHello only includes the client_verify_data, so the (D)TLSS tests have been updated. The renegotiiation_info in the ServerHello contains both client_verify_data and _server_verify_data, so (D)TLSC tests have been left as-is.

@plughy2 Do you have suggestions for updating the (D)TLSS renegotiation Test 4? I have two concerns:

1. What should the expected behavior be for TLS 1.2 if the server chooses to continue a connection without renegotiation (i.e., what do we specifically verify do to verify the server did not
2. Right now it says to send a "hello reset request." I don't see anything in the renegotiation or TLS 1.2 RFC that defines a hello reset request. Am I missing where this is specified or should we provide a better definition?

[plughy2]

For secure renegotiation in TLS version 1.2, either side can initiate a new negotiation after the handshake has completed. The server initiates renegotiation by sending a Hello Request message which tells the client to start a handshake by sending a client hello message over the existing encrypted channel. If the client initiates renegotiation and the TLS 1.2 server doesn't support renegotiation, the server may deny renegotiation from taking place if it chooses to but not terminate the session.

I think NIAP used the wording "Hello Reset Request" but it's really "Hello Request" which is defined in RFC 5246.

My thought is to make Test 4 in FCS_TLSS_EXT.1.8 and FCS_DTLSS_EXT.1.11 applicable to TLS 1.3 only. The reasoning is, if the server denies renegotiation and there's no response, that's not an effective test. It may be appropriate it also make Test 4 in FCS_TLSC_EXT.1.9 and FCS_DTLSC_EXT.1.9 applicable to TLS 1.3 only. There may be TLS 1.2 implementations that have the same behavior on the client.

[kenji-lightship]

For FCS_DTLSS_EXT.1.11 Test 4 and FCS_TLSS_EXT.1.8 Test 4, I think these are OK as-is. Since the non-TOE client is sending a Client Hello, I think the client and server would be out of sync if the TOE tried to ignore the Client Hello.

For FCS_DTLSC_EXT.1.9 Test 4 and FCS_TLSC_EXT.1.9 Test 4, I've edited these to change "Hello Reset Request" to "Hello Request" and changed the pass condition to "does not renegotiate."