Change:
available, a truly random seed MUST be provided from an external source and used with a cryptographically secure pseudorandom number generator.  As each pseudorandom number must only be used once, an <del> implementation needs to get a new truly random seed after reboot, or continuously store state in nonvolatile memory, see (RFC8613, Appendix B.1.1) for issues and solution approaches for writing to nonvolatile memory.  Intentionally or unintentionally weak or </del> <ins> implementation needs to generate unique input to the pseudorandom number generator after reboot, by using a new truly random seed, or by continuously storing unique state in nonvolatile memory, such as strictly increasing sequence numbers.  Appendix B.1.1 in RFC8613 describes issues and solution approaches for writing sequence numbers to nonvolatile memory.  Intentionally or unintentionally weak or </ins> predictable pseudorandom number generators can be abused or exploited for malicious purposes.  RFC8937 describes a way for security protocol implementations to augment their (pseudo)random number

Discussion:
Randomness can be limited in constrained devices, and that can affect EDHOC. Cryptographic Considerations does talk about the necessity of randomness, but it did not become apparent to me from reading that alone that without a new fresh key I not only lose liveness and open up to interleaving, but also run into loss of all security properties when deriving an OSCORE secret from it and neither party has any randomness to put in. If one of the involved parties of EDHOC is just scraping together a few bits of entropy (which is as good as having none), is there a direction in which EDHOC can be used with limited loss of properties? (Gut feeling says no because an attacker can replay a previous EDHOC exchange with them). It may be helpful to also outline how a monotonous counter (similar to that of OSCORE B.1.1) can be used together with a private secret to obtain sufficient randomness. (That may follow from RFC 8937 already, not sure).
Now having read a more recent version of the draft: Looking further into the B.1.1 applicability, one way that'd to me gut-feeling-sounds like it might be OK is that the initiator only saves-to-disk its counter between receiving M2 and before sending M3. Thus, an initiator might use the same ephemeral key twice, but before it completes the exchange, it ensures it will "never" use the same ephemeral key again. The reason this would be useful is that it'd defer the point where the B.1.1 process performs a kind-of-destructive operation (writing to flash that has a finite number of duty cycles) to a point in time when it has good reason to believe that there is actually a peer that makes it worth it. (The response could still be replayed from an adversary that intercepted message1 in an earlier iteration of this, stopped message2 from reaching the device and then injected it now -- but that only gives the attacker one flash write for one time the attacker intercepts messages, and doesn't put the attacker in any better a position than other replays do).
NAME What remains of this issue? Is there anything you want to add to the text?
This part is not explicitly covered and may be worth mentioning or referencing other source. In B.1.1. write to flash is done every k, or when cache is lost.

Why write a counter to flash happen every time EDHOC is run?
NAME NAME Check out . There is a section on mixing.
NAME NAME Thanks for good input here and during the interim! I did not do a good job in explaining what I think remains to do about this issue. Let me try again. Assume for the sake of the argument that there is no randomness contribution at all to the device during operation. The only source of randomness is an initial seed, denoted "private secret" above, which we require to have a good amount of randomness, generated or provisioned during manufacture. We also assume that the device can keep state by writing to non-volatile memory, but this write operation has a cost. In particular the number of write operations are limited. We can now generate pseudo random numbers using the private secret and, say a counter, but we must ensure that each counter value is different and we can't afford storing the counter each time. Section B.1.1 in RFC 8613 describes a procedure with write to flash every K:th step of the counter, where K is set by the application. If the device reboots, it sets counter to K + the value read from flash. More details in the section. Now for potential updates of the draft. Section 8.6 outlines the above. Should we also (in an appendix) give an example (like in RFC 8613 B.1.1.) how to generate random numbers using a secure PRF, the private secret, and sequence numbers, including a procedure for how to read/write from/to flash? Or is that obvious from the references? Section 8.6 says "A good amount of randomness is important for the key generation, to provide liveness, and to protect against interleavin attacks." Should we add something like "and to guard against deriving the same keys twice"? NAME also mentions another optimization whereby the write to flash operation by I is deferred to after R is authenticated. The purpose being to reduce potential write operations. This optimization is contradicting "the ephemeral keys MUST NOT be used in more than one EHDOC message", but could potentially be made secure by aborting after message 2 if the ephemeral key is not fresh. I think we should do 1, neutral about 2, and hesitant to 3.

It is not clear to me that not making this optimization will cause a lot of write to flash.
The text above speaks about section 8.6 (Implementation Considerations) which in -12 to corresponds to section 8.7.
Comparing the randomness considerations in section 8.7 and the example use of non-volatile memory in B.1.1 of RFC 8613, I don't think we need make a separate appendix as suggested in item 1 above. It should be sufficient to add some more hints to section 8.7, a proposal in .
The new text looks good to me. It does not give permission to do the very special case I wanted to do (allow reusing a G_X if and only if the initializer commits to not ever using it again as soon as it has acted on a message 2), but from earlier discussion I conclude that opening up for that would be excessive in this document, and anyone who chooses to not go with what is described best practice will need to make very good own security analyses anyway.
Closing this as is now merged.