> "In short: constructions that concatenate secrets are vulnerable when the underlying hash function is not collision-resistant"

That's quite a condition.

If an attacker can perform discrete logs over EC, and a collision attack is found on SHA-3, then an attacker can encapsulate a malicious secret in Kyber, which when hashed with the 3 ECDH values force the session keys for communications with that attacker to be attacker-chosen values.

In the context of Signal, this means that in a case where an attacker would know the session keys anyway (being one of the parties to the handshake), if ECDH and SHA-3 are both broken, then the attacker could force the session keys to values of their choice.

Certainly there would be cases where this could be a problem, but in the case of Signal, the most disastrous attack I can think of would be maybe some kind of backward MitM attack where two users think they're both talking with the attacker, but they're actually talking with each other.

What am I missing? Yes, the proposed key derivation function ads negligible overhead and loops sound. All else being equal, it's strictly better to not allow the attacker to force the session keys to a attacker-determined values if both ECDH and SHA-3 are broken. However, in this context, the risks associated with a larger code change seem to outweigh the risks of an attacker being able to choose session keys, particularly as it seems a security proof of the proposed key derivation function still seems to be a work in progress.