FCS_TLSC_EXT.1.7 Test (NIT RFI 202410)

[zc20240605]

FCS_TLSC_EXT.1.7 Test in NDcPPv3.0e SD document, as shown below for easy reference, doesn't actually achieve its goal for early data extension:

"The evaluator shall establish a TLS connection with a server and observe that the early data extension and the post-handshake client authentication extension according to RFC 8446 Section 4.2 are not advertised in the Client Hello Message."

If it is a single TLS connection from a TOE (i.e. TLS client) to remote log server, which is the case of such a test, even a client, which can support early data, doesn’t include early_data extension in ClientHello message, as it doesn't even have a session ticket for session resumption.

Specifically, the following test shows that s_client, a TLS client, does include early_data extension in ClientHello when it has both "-sess_in" and "-early_data" options.

echo | openssl s_client -connect :7514 -tls1_3 -sess_in /tmp/session.20201228 -early_data /tmp/http.txt -keylogfile /tmp/key20230605

However, if it only has "-early_data" option, the ClientHello doesn't have early_data extension.

echo | openssl s_client -connect :7514 -tls1_3 -early_data /tmp/http.txt -keylogfile /tmp/key20230605

A TLS server is run with s_server, as shown below:

openssl s_server -accept 7514 -cert bc-sv.cert.pem -key bc-sv.key.pem -CAfile bc-cachain.cert.pem -tls1_3 -early_data

In other word, it is doubtful that inspection of a standalone TLS connection may really achieve its goal of the aforementioned test for early data. There shall be a context for such a test, i.e. an early session which is to be resumed.

Anyway, if such a test cannot be run to determine if TOE (TLS client) supports early data or not, it may need to be removed.

[kenji-lightship]

I believe this was a "best effort" test and not expected to be 100% definitive. Since the TOE is the TLS client (so the tester usually can't fine tune parameters for a connection), it limits the details and way things can be checked.

Based on the description in the issue, I think the test could be improved by requiring an initial connection with a server configured to issue a session ticket, terminate the connection, and verify the next client connection does not include the early data extension. I don't know how much of an improvement this would be as I think there would still be scenarios where an early data extension is not sent even if the TOE supports it.

[kenji-lightship]

The current test is clear and should be able to be run fairly consistently. I can't think of a way to make changes without introducing problems like:

1. It won't be clear under what conditions a TOE will attempt session resumption
2. It won't be clear under what conditions a TOE might or might not have early data to attempt to send
3. Are there differences based on how the Server terminates the initial connection and/or if the initial connection is still open?

I believe changes will increase inconsistency and complicate testing for a marginal gain in assurance.

[kr15tyk]

@ouarak to write up a proposal

[ouarak]

---Proposal ---- FCS_TLSC_EXT.1.7 Test 1: [Conditional: If the TOE supports TLS v1.3 session resumption using PSK.] The evaluator shall follow operational guidance to configure the TOE not to send the Early Data extension. The evaluator shall cause the TOE to establish an initial full handshake TLS 1.3 session with a compliant test TLS 1.3 server, which is configured to send the Early Data Indication extension. The evaluator shall terminate the communication between the TOE and the TLS server. The evaluator shall then cause the TOE to resume the previous TLS session. The evaluator shall confirm that neither the Early Data extension nor any application data were sent by the TOE. Note: If the TOE does not support TLS v1.3 session resumption, this test can be considered not applicable. Test 2: [Conditional: If the TOE supports TLS v1.3 communication using PSK and supports PSK out-of-band provisioning.] The evaluator shall follow operational guidance to configure the TOE not to send the Early Data extension. The evaluator shall cause the TOE to establish a TLS 1.3 session between the TOE and a TLS 1.3 server. Using a network traffic sniffer, the evaluator shall confirm that neither the Early Data extension nor any application data were sent by the TOE. Note: If the TOE does not support sending early data to a TLS v1.3 server using out-of-band PSK provisioning, this test can be considered not applicable. Test 3: The evaluator shall establish a TLS connection with a server. The evaluator shall observe that the post-handshake client authentication extension, according to RFC 8446 Section 4.2, is not advertised in the ClientHello message.

[kenji-lightship]

I disagree with the changes. This doesn't address my concerns over clarity, repeatability, and broad applicability.

Test 1:

• "test TLS 1.3 server, which is configured to send the Early Data Indication extension." There is not an "Early Data Indication extension." How does this work in practice? "Configured to" does not necessarily result in anything happening. If this wouldn't result in any change, why is this part of the test?
• "terminate the communication between the TOE and the TLS server. The evaluator shall then cause the TOE to resume the previous TLS session." How is this done? What if a TOE only resumes sessions that it has gracefully closed itself? What if a TOE only uses session resumption to establish additional sessions?

Test 2: The conditional "PSK out-of-band provisioning" is not allowed by the PP.

[kr15tyk]

THe TLS working group voted 6 to 1 to recommend that the NIT reject this RFI. Note that the next version of the NDcPP is expected to point out to NIAP's FP for TLS, and the TLSWG is working in conjunction with NIAP's TLS TC.