Provide the location of the issue
Application note 63/101 in the cPP (3.0e draft), has a table to help understand the scope of selections when it comes to the use of the supported_groups extension in the Client Hello and ciphersuites. For (D)TLS 1.2 implementations which do not support advertising named ffdhe groups in the supported_groups extension for DHE ciphersuites (e.g. OpenSSL), the application note plus the associated AAs in the SD create a conflict.
What is the correction request for the cPP? Please describe.
If a TOE (D)TLS client (that doesn’t expressly negotiate FFC DHE parameters) supports both DHE and ECDHE ciphers while communicating with a (D)TLS 1.2 server, then the TOE TLS client will end up with a supported_groups extension listing only secp groups. This is expected and I believe the intent of the note in the table in the application note: "This extension is not required, because older TLS implementations did not negotiate FFC parameters". However, the conflict arises because an ST will have to claim "present the Supported Groups Extension" which means that the table forces the ST author to have to claim "at least one ffdhe group shall be selected" which could never be realized by otherwise industry-conforming implementations of OpenSSL.
Describe the solution you'd like
In the application note 63/101, the table should be modified to capture the nuances:
not present the Supported Groups Extension
present the Supported Groups Extension
...
...
...
(D)TLS 1.2 with support for at least one DHE ciphersuite
May select - This extension is not required if DHE is the only supported ciphersuite, because older TLS implementations did not negotiate FFC parameters (e.g. Group 14).
May select – at least one ffdhe group should be selected if the TOE negotiates FFC parameters, otherwise no ffdhe groups are required
In sections 4.2.1.1 (DTLS) and 4.2.6.1 (TLS), replace the TSS:
If “present the Supported Groups Extension” is selected, the evaluator shall verify that TSS describes the Supported Groups Extension and whether the required behaviour is performed by default or may be configured. If TLS 1.2 is claimed and DHE ciphers are claimed, then the TSS must also specify whether the TOE is capable of negotiating DHE ciphers and whether the TOE client will terminate if an unsupported DHE parameter set is returned in the Server Key Exchange or whether all valid server-generated DHE parameters are accepted.
In sections 4.2.1.3 (DTLS) and 4.2.6.3 (TLS), test case 4 needs to be updated:
Test 4a [conditional, for TLS 1.3 only]: If ffdhe curves are selected, the evaluator shall configure the server to perform a DHE key exchange in the TLS connection using a non-supported group and shall verify that the connection fails and no application data flows. The non-supported group shall be as similar to the selected group(s) as possible (i.e. a non-selected group when not all groups are selected or undefined Codepoint 0x0105 (ffdhe8192 + 1)).
Test 4b [conditional, for TLS 1.2 only]: If ffdhe curves are selected, the evaluator shall configure the server to return DHE parameters in the Server Key Exchange in the TLS connection that do not meet the construction for any claimed ffdhe group. The evaluator shall verify that the connection fails and no application data flows. If the TOE client supports any server-returned DHE parameter set, then this test is not applicable.
Describe alternatives you've considered
There do not appear to be any interpretations in the way the application note is worded to permit OpenSSL from being considered conforming.
I did consider adjusting the test cases, but I think all of the test cases (with the exception of test case 4 for dealing with RFC 7919) stand up properly even in the face of protocol version/cipher nuances. For example:
A TLS 1.3 capable client talking to a TLS 1.2 server (or a TLS 1.2 client): the TLS 1.2 server has no concept of a confirmation of supported group in the Server Hello. Rather, the server will implicitly signal use of the group if it returns a Server Key Exchange with the appropriate parameters. The TLS client is required to process this if it advertises support for ffdhe in its Client Hello. Since RFC 7919 permits TLS clients to continue processing even if the returned group is not aligned with the advertised set, I added TSS requirements to document the TLS client behaviour and a test case to check for explicit verification of the TOE client to validate the DH parameters in the Server Key Exchange (if such behaviour is enforced).
If only DHE ciphers are presented and the client is not capable of negotiating FFC groups, then the ST author would have selected "Not present the Supported Groups Extension" and only test case 1 is performed (verify the extension isn't sent).
If a mix of DHE and ECDHE ciphers are presented and the client is not capable of negotiating FFC groups, then the ST author would have selected only secp groups to appear in the Supported Groups extension and test cases 2 and 3 are performed. The adjusted wording in the application note(s) would ensure this is a valid operation.
If a mix of DHE and ECDHE ciphers are presented and the client is capable of negotiating FFC groups, then the ST author would have selected both secp and ffdhe groups to appear, and test cases 2, 3 and 4 would be performed.
Provide the location of the issue Application note 63/101 in the cPP (3.0e draft), has a table to help understand the scope of selections when it comes to the use of the supported_groups extension in the Client Hello and ciphersuites. For (D)TLS 1.2 implementations which do not support advertising named ffdhe groups in the supported_groups extension for DHE ciphersuites (e.g. OpenSSL), the application note plus the associated AAs in the SD create a conflict.
What is the correction request for the cPP? Please describe. If a TOE (D)TLS client (that doesn’t expressly negotiate FFC DHE parameters) supports both DHE and ECDHE ciphers while communicating with a (D)TLS 1.2 server, then the TOE TLS client will end up with a supported_groups extension listing only secp groups. This is expected and I believe the intent of the note in the table in the application note: "This extension is not required, because older TLS implementations did not negotiate FFC parameters". However, the conflict arises because an ST will have to claim "present the Supported Groups Extension" which means that the table forces the ST author to have to claim "at least one ffdhe group shall be selected" which could never be realized by otherwise industry-conforming implementations of OpenSSL.
In sections 4.2.1.1 (DTLS) and 4.2.6.1 (TLS), replace the TSS: If “present the Supported Groups Extension” is selected, the evaluator shall verify that TSS describes the Supported Groups Extension and whether the required behaviour is performed by default or may be configured. If TLS 1.2 is claimed and DHE ciphers are claimed, then the TSS must also specify whether the TOE is capable of negotiating DHE ciphers and whether the TOE client will terminate if an unsupported DHE parameter set is returned in the Server Key Exchange or whether all valid server-generated DHE parameters are accepted.
In sections 4.2.1.3 (DTLS) and 4.2.6.3 (TLS), test case 4 needs to be updated: Test 4a [conditional, for TLS 1.3 only]: If ffdhe curves are selected, the evaluator shall configure the server to perform a DHE key exchange in the TLS connection using a non-supported group and shall verify that the connection fails and no application data flows. The non-supported group shall be as similar to the selected group(s) as possible (i.e. a non-selected group when not all groups are selected or undefined Codepoint 0x0105 (ffdhe8192 + 1)).
Test 4b [conditional, for TLS 1.2 only]: If ffdhe curves are selected, the evaluator shall configure the server to return DHE parameters in the Server Key Exchange in the TLS connection that do not meet the construction for any claimed ffdhe group. The evaluator shall verify that the connection fails and no application data flows. If the TOE client supports any server-returned DHE parameter set, then this test is not applicable.
Describe alternatives you've considered There do not appear to be any interpretations in the way the application note is worded to permit OpenSSL from being considered conforming.
I did consider adjusting the test cases, but I think all of the test cases (with the exception of test case 4 for dealing with RFC 7919) stand up properly even in the face of protocol version/cipher nuances. For example: