FCS_(D)TLS(C/S)_EXT.1.4 Updates

[rguthrie1324]

Updating four SFRs and their respective application notes in the associated branch (50-fcs_tlsc_ext14-updates):

1. FCS_TLSC_EXT.1.4
2. FCS_DTLSC_EXT.1.4
3. FCS_TLSS_EXT.1.4
4. FCS_DTLSS_EXT.1.4

Also updating other text outside of these SFRs.

[rguthrie1324]

Changes (made in c9e023d):

• Removed reference to RFC5246 after signature_algorithms extension (referencing only RFC8446).
• Removed IANA values trailing secp and ffdhe parameters.
• Changed all instances (not just in these four SFRs) of "ecdsa-" to "ecdsa_"
• Replaced some instances of 'deprecated' with 'disallowed' (when 'deprecated was inaccurate, e.g. for AES-128) (did not change name of test-id even when term is changed within the description, in case this would cause any negative interaction with references to the ids).
• In DTLSC and DTLSS, "TLS ClientHello" -> "DTLS ClientHello" and "TLS" -> "DTLS" in bullet about supported_versions extension.

[rguthrie1324]

To Do

1.
FCS_DTLSC_EXT.1.4 and FCS_DTLSS_EXT.1.4 should sometimes point to RFC9147 (DTLS 1.3) instead of RFC8446 (TLS 1.3) and RFC6347 (DTLS 1.2) instead of RFC5246 (TLS 1.2).

This is not necessarily a blanket change of 8446 to 9147 and 5246 to 6347 though, for two reasons:

• Some mentions of 8446 and 5246 may stay the same (e.g. if an extension is defined in either of those RFCs)
• Some more substantive changes may be required (e.g. DTLS may use a different extension than TLS in some instances).

Note that this change may be required for SFRs beyond FCS_DTLS(C/S)_EXT.1.4.

[rguthrie1324]

To Do

2.
RFC 9151 (CNSA 1.0) (https://datatracker.ietf.org/doc/html/rfc9151 Section 4) requires either ECDH with P-384 or DH with 3072 or 4096 bit prime modulus be used, and is also okay with RSA with 3072 or 4096 prime bit modulus for (D)TLS 1.2 specifically.

Formatting of the selections in FCS_TLSS_EXT.1.5 does not align with this. Need to update.

Also need to see if this change is needed for (D)TLS(S/C).

[rguthrie1324]

Question

3.
The phrase "key exchange message" is used several times and I'm not sure what it means. Should it be ServerHello or ClientHello?

In particular, some of the phrasing I see seems a bit vague.

As an example, "If the TSF supports DTLS 1.2, supports DHE ciphersuites, and supports DHE groups in the supported groups extension, then for each supported DHE group, the evaluator shall send the TSF a compliant DTLS 1.2 ClientHello indicating a single ciphersuite that is compatible with the group and indicating the group in the supported groups extension. The evaluator shall observe that the TSF negotiates DTLS 1.2 using the indicated ciphersuite and that the server key exchange message indicates the specific group. The evaluator shall send the TOE a client key exchange with a valid point in the group and observe that the TSF successfully completes the session."

I don't really know what is meant by "send... a client key exchange" - you can perform a key exchange, but you can't send a key exchange. I think it should say ClientHello, but ClientHello wouldn't be a direct replacement for 'client key exchange' because I think the key_share extension might need to be referenced too.

All of this is to illustrate that some of this language might be clearer if the exact name of messages, extensions, etc. from the TLS RFCs were used.

[rguthrie1324]

More changes (made in b9ca6ea):

• Changed some instances of "key exchange" to "key establishment" but did not update in language about messages in testing activities nor in ids.
• There were a lot of "hello reset request" and "hello reset" mentions. There are no messages with "reset" in the name. I changed all of these to "HelloRetryRequest" which is defined for TLS 1.3, but it is possible that some or all should have been "HelloRequest" which is defined only for renegotiation in TLS 1.2. Please double-check what was intended.
• Changed extension names to have correct syntax (e.g. "supported_versions" instead of "supported version").
• Changed "server hello" to "ServerHello" and "client hello" to "ClientHello"

[rguthrie1324]

Question

4.

I see this excerpt: "The evaluator shall observe that the TSF presents a ClientHello indicating DTLS 1.2 (value 'fe fd') in the highest or legacy version field and, if DTLS 1.3 is supported, the "supported versions" extension is present and contains the value 'fe fc' for DTLS 1.3"

But this seems like it might contradict the supported_versions extension language in the _EXT.1.4 SFRs. Specifically, the way the selections are formatted in those SFRs requires support for 1.3 and optionally allows support for 1.2 in addition to 1.3.

So following the language in the _EXT.1.4 SFRs would not let supported_versions only indicate 1.2.

Moreover, supported_versions was defined for (D)TLS 1.3, not 1.2. I'm not sure 1.2 can always understand it.

However, I do not see the excerpt I included initially in https://commoncriteria.github.io/tls/master/tls-release.html, so I can't say for sure that the context makes this okay somehow.

So, does either the excerpt quoted initially or the wording in the _EXT.1.4 SFRs need to be changed? Note that the excerpt quoted appears a few times throughout tls.xml so it would need to be updated in more than one place.

[rguthrie1324]

To Do

5.

In the near future, it would be good to split a lot of these SFRs into separate SFRs for TLS 1.2 and TLS 1.3 because the protocols are so different. It could be good to do this when adding in support for ML-KEM and ML-DSA, because TLS 1.2 will not support those algorithms anyway.

[rguthrie1324]

Question

6.

Should any of the SFRs relating to certificates reference RFC8603?

FCS_DTLSC_EXT.1.5 looks like it would be a good place.

[rguthrie1324]

To Do

7.

Add in support for RFC 8773 PSK for TLS 1.3.

This will include adding in language to the FCS_(D)TLS(C/S)_EXT.1.4 SFRs and perhaps other places too (TBD).

[rguthrie1324]

Change (made in 443ff9d):

• Changed language about (D)TLS versions (443ff9d) in alignment with old pull request for same issue (Explicitly preclude earlier than TLS 1.2 #27)

[rguthrie1324]

Question

8.

In FCS_DTLSC_EXT.1.2, the selection for TLS 1.2 ciphersuites says "and shall not offer other TLS 1.2 ciphersuites" while the selection for TLS 1.3 ciphersuites includes an assignment for "other TLS 1.3 ciphersuites"

What is the explanation for the disparity between these?

Note that this may also apply to FCS_(D)TL(C/S)_EXT.1.2 SFRs.

[rguthrie1324]

Change (made in 5d74ed1):

• Added TLS 1.2 ciphersuite allowed in RFC 9151 but missing from list here.

[rguthrie1324]

Question

9.

FCS_(D)TLSC_EXT.1.3 both impose a requirement on the ClientHello message, but then the application notes say, "In addition, this requirement prohibits Using Raw Public Keys in Transport Layer Security and Datagram Transport Layer Security (RFC 7250) for server certificates." This doesn't make sense because the SFR is ClientHello does not contain a server certificate.

I'm not sure what the intent was.

[rguthrie1324]

Question

10.

FCS_DTLSC_EXT.1.7 says, "The TSF shall [selection: terminate the DTLS session, silently discard the record] if a message received contains an invalid MAC or if decryption fails in the case of GCM and other AEAD ciphersuites."

In particular, looking at that last part "in the case of GCM and other AEAD ciphersuites" - GCM is the only AEAD ciphersuite that appears in this FP.

I think this phrasing is redundant because of that.

There are two options:

1. Just say GCM and not AEAD (this is not my preference because AES-GCM-SIV may be added in the future and then we'd have to re-expand everything to say AEAD)
2. Just say AEAD and not GCM (this is my preference - it would be clear because the description in the application note below FCS_DTLSC_EXT.1.3 implicitly states that GCM is AEAD- it could be stated explicitly as well (ideally in an application note instead of in an SFR).

Note: For some reason the is no TLS SFR equivalent to FCS_DTLSC_EXT.1.7.