[cPP Comment 52] Testing of TLS 1.3

[kr15tyk]

Location: SD: 3.6.1, 3.6.3, 4.2.6, 4.2.7 Comment: Testing of TLS 1.3 implementations are incomplete, due to assumptions on the test environment. Suggested Change: Test environment will need to include modified test TLS servers for (D)TLSC testing and modified test TLS clients for (D)TLSS testing. Omitted tests for TLS 1.3 would allow flawed implementations to pass validation.

[kr15tyk]

8/31/23 – Per Al (NIAP SME), he will send a few sample tests for TLS 1.3 to reject secure negotiation which should be a simple add/fix for this comment.

[kr15tyk]

Sample tests (with SFR edits) provided by NIAP on 9/7/23:

The following tests pull language directly from the TLS Functional Package v2.0 to address the gaps for TLS 1.3 testing in the NDcPP v3.0.

Note they are written assuming the indicated updates to SFR:

FCS_TLSC_EXT.3 TLS Client Support for secure renegotiation (TLSv1.2 only)

FCS_TLSC_EXT.3.1 The product shall [selection: support secure renegotiation through use of the “renegotiation_info” TLS extension in accordance with RFC 5746, reject renegotiation attempts].

Application note: the first option applies only to TLS 1.2 functionality and is selected if TLS 1.2 supports secure renegotiation. The second option applies either to TLS 1.2 or TLS 1.3, and must be selected if TLS 1.3 is claimed. The ST author will describe which supported versions the second option applies to, if claimed.

Test FCS_TLSC_EXT.4:2.1: (TLS 1.2) [conditional] If the TSF supports a configuration to reject TLS 1.2 renegotiation, the evaluator shall follow the operational guidance as necessary to prevent renegotiation. The evaluator shall initiate a TLS session between the so-configured TSF and a test TLS 1.2 server that is configured to perform a compliant handshake, followed by a hello reset request. The evaluator shall confirm that the TSF completes the initial handshake successfully but terminates the TLS session after receiving the hello reset request. Note: It is preferred that the TSF sends a fatal error alert message (e.g., unexpected message) in response to this, but it is acceptable that the TSF terminates the connection silently (i.e., without sending a fatal error alert).

Test FCS_TLSC_EXT.4:2.2: [conditional] If the TSF supports TLS 1.3, the evaluator shall initiate a TLS session between the TSF and a test TLS 1.3 server that completes a compliant TLS 1.3 handshake, followed by a hello reset message. The evaluator shall observe that the TSF completes the initial TLS 1.3 handshake successfully, but terminates the session on receiving the hello reset message. It is preferred that the TSF sends a fatal error alert message (e.g., unexpected message) in response to this, but it is acceptable that the TSF terminates the connection silently (i.e., without sending a fatal error alert).

FCS_TLSS_EXT.3 TLS Server Support for secure renegotiation (TLSv1.2 only)

FCS_TLSS_EXT.3.1 The product shall [selection: support secure renegotiation in accordance with RFC 5746 by always including the ”renegotiation_info” extension in ServerHello messages, reject attempts to renegotiate].

Application note: the first option applies only to TLS 1.2 functionality and is selected if TLS 1.2 supports secure renegotiation. The second option applies either to TLS 1.2 or TLS 1.3, and must be selected if TLS 1.3 is claimed. The ST author will describe which supported versions the second option applies to, if claimed.

Test FCS_TLSS_EXT.4:2.5: [conditional] If the TSF supports TLS 1.3, or if the TSF rejects renegotiation for TLS 1.2, then for each such version, the evaluator shall follow the operational guidance as necessary to configure the TSF to negotiate the version and reject renegotiation. The evaluator shall initiate a valid initial session for the specified version, send a valid client hello on the non-renegotiable TLS channel, and observe that the TSF terminates the session. Note: It is preferred that the TSF sends a fatal error alert message (e.g., unexpected message) in response to this, but it is acceptable that the TSF terminates the connection silently (i.e., without sending a fatal error alert).

Equivalent modifications following the instructions for DTLS:

FCS_DTLSC_EXT.3 DTLS Client Support for secure renegotiation (DTLSv1.2 only)

FCS_DTLSC_EXT.3.1 The product shall [selection: support secure renegotiation through use of the “renegotiation_info” DTLS extension in accordance with RFC 5746, reject renegotiation attempts].

Application note: the first option applies only to DTLS 1.2 functionality and is selected if DTLS 1.2 supports secure renegotiation. The second option applies either to DTLS 1.2 or DLS 1.3, and must be selected if DTLS 1.3 is claimed. The ST author will describe which supported versions the second option applies to, if claimed.

Test FCS_DTLSC_EXT.4:2.1: (DTLS 1.2) [conditional] If the TSF supports a configuration to reject DTLS 1.2 renegotiation, the evaluator shall follow the operational guidance as necessary to prevent renegotiation. The evaluator shall initiate a TLS session between the so-configured TSF and a test DTLS 1.2 server that is configured to perform a compliant handshake, followed by a hello reset request. The evaluator shall confirm that the TSF completes the initial handshake successfully but silently drops the hello reset message or terminates the DTLS session after receiving the hello reset request. If the TSF does not terminate the session, the evaluator shall attempt to repeatedly send the hello reset message until it does, or until the timeout for the session is reached.

Note: It is preferred that the TSF sends a fatal error alert message (e.g., unexpected message) in response to this, but it is acceptable that the TSF terminates the connection silently (i.e., without sending a fatal error alert).

Test FCS_DTLSC_EXT.4:2.2: [conditional] If the TSF supports DTLS 1.3, the evaluator shall initiate a DTLS session between the TSF and a test DTLS 1.3 server that completes a compliant DTLS 1.3 handshake, followed by a hello reset message. The evaluator shall observe that the TSF completes the initial DTLS 1.3 handshake successfully, but silently ignores the hello reset message or terminates the session on receiving the hello reset message. If the TSF does not terminate the session, the evaluator shall attempt to repeatedly send the hello reset message until it does, or until the timeout for the session is reached.

If termination is observed, it is preferred that the TSF sends a fatal error alert message (e.g., unexpected message) in response to this, but it is acceptable that the TSF terminates the connection silently (i.e., without sending a fatal error alert).

FCS_DTLSS_EXT.3 TLS Server Support for secure renegotiation (DTLSv1.2 only) FCS_DTLSS_EXT.3.1 The product shall [selection: support secure renegotiation in accordance with RFC 5746 by always including the ”renegotiation_info” extension in ServerHello messages, reject renegotiation attempts].

Application note: the first option applies only to DTLS 1.2 functionality and is selected if DTLS 1.2 supports secure renegotiation. The second option applies either to DTLS 1.2 or DLS 1.3, and must be selected if DTLS 1.3 is claimed. The ST author will describe which supported versions the second option applies to, if claimed.

Test FCS_DTLSS_EXT.4:2.5: [conditional] If the TSF supports DTLS 1.3, or if the TSF rejects renegotiation for DTLS 1.2, then for each such version, the evaluator shall follow the operational guidance as necessary to configure the TSF to negotiate the version and reject renegotiation. The evaluator shall initiate a valid initial session for the specified version, send a valid client hello on the non-renegotiable TLS channel, and observe that the TSF silently ignores the hello message or terminates the session. If the TSF does not terminate the session, the evaluator shall attempt to repeatedly send the hello message until it does, or until the timeout for the session is reached.

Note: If termination is observed, it is preferred that the TSF sends a fatal error alert message (e.g., unexpected message) in response to this, but it is acceptable that the TSF terminates the connection silently (i.e., without sending a fatal error alert).