Change:
If two nodes unintentionally initiate two simultaneous EDHOC message exchanges with each other even if they only want to complete a single EDHOC message exchange, they MAY terminate the exchange with the <del> lexicographically smallest G_X.  If the two G_X values are equal, the received message_1 MUST be discarded to mitigate reflection attacks. Reflection attacks are not possible when the other endpoint's identity is verified, but could be a problem with trust on first use (TOFU) and future EHDOC methods using e.g., pre-shared keys.  Note that in cases where several EDHOC exchanges with different parameter sets (method, COSE headers, etc.) are used, an attacker can affect which of the parameter sets that will be used by blocking some of the parameter sets. </del> <ins> lexicographically smallest G_X.  Note that in cases where several EDHOC exchanges with different parameter sets (method, COSE headers, etc.) are used, an attacker can affect which of the parameter sets that will be used by blocking some of the parameter sets. </ins> If supported by the device, it is RECOMMENDED that at least the long- term private keys are stored in a Trusted Execution Environment (TEE)

Discussion:
Removed the G_X checking that is heavy for implementations. That was a left over from the PSK mehtod.
Based on Marco's comment. Maybe we should not have details.... Remoded details on ID_CRED Reforormulated in split into tofu and non tofu Renamed to selfie attack. (reflection attack was used earlier for the same thing but can also be other types of attacks) So-called selfie attacks are mitigated as long as the Initiator does not have its own identity in the set of Responder identities it is allowed to communicate with. In trust on first use (TOFU) use cases the Initiator should verify that the the Responder's identity is not equal to its own. Any future EHDOC methods using e.g., pre-shared keys might need to mitigate this in other ways.
In the Editor's copy, the second bullet point at [1] says: Could you clarify the exact meaning of "simultaneous EDHOC message exchange" and which of the existing EDHOC sessions should be checked? In particular, is this limited to checking the sessions that the Responder has started but are still not completed, while simply skipping all the other ones? If so, can a session be considered completed when TH_4 has been computed and stored, or even earlier than that? [1] https://lake-URL
Yes, let's clarify that.
It would also help narrowing that statement to where it is actually relevant. Reading over "all the state" in a system can be costly, and becomes less and less well-defined the more a system becomes distributed. Reading (for example, if that is the case) over "all the state of exchanges that use a particular PSK" would be more doable.
I certainly agree.
I agree. The GX is a leftover from the time when we had a PSK mode, It was left as it theoretically is a nice way to stop selfie-attacks for future methods. Given the practical problems and that this is not needed for any of the current methods with mutual authentication I think it should be removed from processing and moved back to security considerations.

For method 0-3 with mutual authentication, selfie-attacks are not a problem, I will authenticate R. For method 0-3 with TOFU, selfie-attacks are a problem, but can then be solved by the looking at CREDR and making sure CREDR was not previously sent by I. This is easier to do then checking active GX. For a hypothetical future EDHOC PSK mode, selfie-attack can be mitigated by doing the G_X check, assign strict roles (I or R) to each PSK, or adding some identifier string to e.g. EAD ("42-50-31-FF-EF-37-32-39").
I made a PR which should address all the aspects of this issue. Deleted all GX checking text Separated reflection attack checking from simultanous sessions. Added the following text To mititgate reflection attacks, the Initiator MUST verify that the the Responder's identity is not equal to Initiator's, e.g., by checking that IDCREDR was not previosly created by the Intiator. Any future EHDOC methods using e.g., pre-shared keys might need to mitigate this in other ways. Should it be mentioned in message2 processing? Should it be MUST? Should it take specifically about TOFU?
Addresses Marcos comments. Seems to be agreement on new text. Merging and closing