FCS_TLSC_EXT.1.4 extended_master_secret likely not conformant to most servers

[woodbe]

Support for this is available on clients but it has been up to the server to request it, which the client can then do. Forcing the client to require this likely will mean that the client is non-viable for general use today as it isn't clear just how many servers do actually have this support. This again would seem to point to requiring a special mode of operation on client libraries to be compliant here for something that should be handled by the server.

Requiring the client to support this when a server asks is fine, but forcing the client to only talk to servers that have this is a problem.

[woodbe]

It isn't clear exactly how the change here may address this concern. It seems like it is a selection, but then the app note says "if you use TLS 1.2 you have to select this" which isn't really then a selection. This seems like the app note is normative, not informative, and that the requirement should make this a requirement if TLS 1.2 is chosen in FCS_TLSC_EXT.1.1.

In any case, the statement still stands, it isn't exactly clear what the intent here is, whether it is to mandate that the client must ask or that it should support the capability.

[jfisherbah]

RFC 7627 states:

In all handshakes, a client implementing this document MUST send the
"extended_master_secret" extension in its ClientHello.

The app note is normative guidance but historically we haven't completely foolproofed SFRs from the possibility of hostile compliance. That coupled with the reference to RFC 7627 makes it reasonably clear that this is always required in the case of TLS 1.2.

With regards to the original question, RFC 7627 says that while a client MUST offer the suggestion, both the client and the server's ability to abort the connection without it is only a SHOULD in both directions.

If the TSF offers the extension and the server responds with the extension, it is a reasonable assumption that the TSF will proceed with using the extended master secret, even though the standard doesn't technically say that.

If the TOE offers the extension and you want to have the ability for the TSF to continue with the connection without receiving it in response, you would select "allowing legacy servers." The use case where it aborts the connection unless the server offers the extension would be when "no other enforcement mode" is selected.

Right now the clause is saying, colloquially:

• If the TSF supports TLS 1.2 it is mandatory for it to offer the extension
• If the TSF aborts the connection when it doesn't receive the extension back in response, make one selection. If the TSF ignores the absence of the extension and proceeds, make the other selection

[jfisherbah]

Note that upon further review the current testing for this requirement (FCS_TLSC_EXT.1:4.3) appears to have two gaps relative to the SFR.

1. The first part of the test says the evaluator shall initiate a TLS 1.2 session with a test TLS server configured to compute a master secret according to RFC 5246, section 8. This is incorrect because the master secret is not the same as the extended master secret, so a server configured to support extended master secret would not be configured to computer a master secret, by definition. This should reference RFC 7627, section 4 instead. Additionally, there should be a statement at the end that says the evaluator shall observed that the connection is successful - this is sufficient evidence to conclude that the extended master secret is negotiated, because we can assume the server is behaving correctly and if the TSF did not behave correctly, there would be a decryption failure and the connection would not succeed.

2. The second part of the test says that if the server does not include the extended master secret, the TSF terminates the connection. This is only going to happen if "no other enforcement mode" is selected. We also need a test case for when "allowing legacy server support" is selected because in that case, the server will not offer the extended master secret, and the TSF will therefore revert to the RFC 5246 master secret.

Additionally it would probably help to do these as sub-tests, as most of the rest of the SFR is done. But that is just a semantic comment.