FCS_TLSC_EXT.1.7 Test

[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.