Why NIST 800-56A rev3 does not use cross secret calculation in C(2e, 2s, ECC CDH) scheme?

In the NIST 800-56A rev3 "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography" in section 6.1.1.2 "(Cofactor) Full Unified Model, C(2e, 2s, ECC CDH) Scheme" the shared secret is calculated as follows:

Party U Calculates:

1. $Z_s = d_{s,U} Q_{s,V}$
2. $Z_e = d_{e,U} Q_{e,V}$
3. $Z = Z_s || Z_e$

Party V Calculates:

1. $Z_s = d_{s,V} Q_{s,U}$
2. $Z_e = d_{e,V} Q_{e,U}$
3. $Z = Z_s || Z_e$

where $d_{s,X}, Q_{s,X}$ are the static private and public keys of party $X$ respectively and $d_{e,X}, Q_{e,X}$ are the ephemeral private and public keys of party $X$ respectively.

However, this scheme is vulnerable to "Key Compromise Impersonation" (KCI) attacks. This means if someone obtains $d_{s,U}$, they can impersonate any other party to $U$. The same is true for $V$. This is also acknowledged in the NIST publication and also see here for more details.

As far as I can see, if we cross calculate the shared secrets as follows:

Party U Calculates:

1. $Z_1 = d_{s,U} Q_{e,V}$
2. $Z_2 = d_{e,U} Q_{s,V}$
3. $Z = Z_1 || Z_2$

Party V Calculates:

1. $Z_2 = d_{s,V} Q_{e,U}$
2. $Z_1 = d_{e,V} Q_{s,U}$
3. $Z = Z_1 || Z_2$

we can prevent KCI attacks without compromising any other assurance given by the scheme.

I understand that this breaks the symmetry between parties, i.e. now both parties must know which role they are in. But in my mind this would be a much simpler scheme if parties already know their roles, which is implicitly assumed for some other schemes by the way.

So, my question is, am I missing something here? Has this scheme got all the assurances given in "Table 23: Summary of assurances"?

The proposed protocol looses the Forward Secrecy that the original protocol offers. Recall that's defined in NIST SP 800-56A Rev. 3 as

Forward Secrecy (FS): Assurance obtained by one party in a key-agreement transaction that the keying material derived during that transaction is secure against the future compromise of the static private key-agreement keys (if any) of the participants.

Notice that with the static private keys $d_{s,U}$ and $d_{s,V}$, and a transcript of a transaction of the proposed protocol (which will include $Q_{e,U}$ and $Q_{e,V}$), we can compute $$Z:=(d_{s,U}\,Q_{e,V})\mathbin\|(d_{s,V}\,Q_{e,U})$$

Proposition to get the best of the two protocols, while remaining symmetric.

Party $U$ does

• $Z_s:=d_{s,U}\,Q_{s,V}$
• $Z_e:=d_{e,U}\,Q_{e,V}$
• $Z_{1,U}:=d_{s,U}\,Q_{e,V}$
• $Z_{2,U}:=d_{e,U}\,Q_{s,V}$
• $Z:=Z_s\mathbin\|Z_e\mathbin\|\min(Z_{1,U},Z_{2,U})\mathbin\|\max(Z_{1,U},Z_{2,U})$

and the other party $V$ does

• $Z_s:=d_{s,V}\,Q_{s,U}$
• $Z_e:=d_{e,V}\,Q_{e,U}$
• $Z_{1,V}:=d_{s,V}\,Q_{e,U}$
• $Z_{2,V}:=d_{e,V}\,Q_{s,U}$
• $Z:=Z_s\mathbin\|Z_e\mathbin\|\min(Z_{1,V},Z_{2,V})\mathbin\|\max(Z_{1,V},Z_{2,V})$

$Z$ is shared, can be used for session key derivation, and I think this is KCI secure. Aside from side channel issues (which are manageable), and computational cost about doubled, I don't see any drawback compared to the original protocol.

The way one avoids KCI attacks in C(2e, 2s) is to obtain assurance of the possession of a private static key as per Section 5.6.2.2.3.

In NIST SP 800-56A Rev. 3, this is unfortunately not considered necessary and therefore not part of their schemes, because in their description of the C(2e, 2s) schemes, they assume it was done, see Section 6.1.1 where they say it is an assumption that:

6. The recipient of a static public key has obtained assurance that its (claimed) owner is (or was) in possession of the corresponding static private key, as specified in Section 5.6.2.2.3.

The typical way of performing such validation is just like explained in Section 5.6.2.2.3 (emphasis mine):

1. The recipient of the static public key contributes an ephemeral public key to the key-agreement process, one that is intended to be arithmetically combined with the claimed owner’s (i.e., the other party’s) static private key in computations performed by the claimed owner. (If an appropriate key-agreement scheme is employed, the claimed owner will be challenged to demonstrate current knowledge of his static private key by successfully performing those computations during the transaction.)

But as you've pointed out, both FFC DH and ECC CDH C(2e, 2s) schemes are not mixing the ephemeral keys with the static keys and so are vulnerable to KCI attacks unless the assurance of the possession of the private static key was obtained prior to running them, which is assumed. This is why they don't need to do anything fancy to mix ephemeral keys and static keys to achieve it.

Real world protocols (e.g. Signal's protocol) typically achieve this by signing ephemeral keys using the static keys during the ephemeral key exchange. Then you cannot sign your public ephemeral key without knowledge of the static secret key, and therefore you cannot impersonate someone to the first party by only knowing this party's private static key.