Change:
Comment by Robert Moskowitz
I think the forward secrecy could use some more text. Right know we are using the definition according to the IETF security dictionary, but as the security dictionary states, a lot of different definitions is used. The draft that the KeyUpdate gives much better security than using a single key, but that the KeyUpdate method gives a lower security level than frequently running ephemeral diffie-hellman

Discussion:
in deployments where no protected application data is sent from R to I. <del> A key material exporter and a key update function enabling frequent forward secrecy. </del> <ins> A key material exporter and a key update function enabling forward secrecy. </ins> Verification of a common preferred cipher suite:

The EDHOC-KeyUpdate takes a nonce as input to guarantee that there are no short cycles.  The Initiator and the Responder need to agree <del> on the nonce, which can e.g., be a counter or a random number. </del> <ins> on the nonce, which can e.g., be a counter or a random number.  While the KeyUpdate method provides forward secrecy it does not give as strong security properties as re-running EDHOC, see security. </ins> 5.

the Initiator and the Responder. As required by RFC7258, IETF protocols need to mitigate pervasive <del> monitoring when possible.  One way to mitigate pervasive monitoring is to use a key exchange that provides forward secrecy.  EDHOC therefore only supports methods with forward secrecy.  To limit the effect of breaches, it is important to limit the use of symmetrical group keys for bootstrapping.  EDHOC therefore strives to make the additional cost of using raw public keys and self-signed certificates as small as possible.  Raw public keys and self-signed certificates are not a replacement for a public key infrastructure but SHOULD be used instead of symmetrical group keys for bootstrapping. </del> <ins> monitoring when possible.  EDHOC therefore only supports methods with ephemeral Diffie-Hellman and provides a KeyUpdate function for lightweight application protocol rekeying with forward secrecy.  As discussed in RFC4949 the term "forward secrecy" is a muddled area. EDHOC provides forward secrecy in the sense that compromise of the private authentication keys does not compromise past session keys, and compromise of a session key does not compromise past session keys. While the KeyUpdate method can be used to meet cryptographic limits and provide partial protection against key leakage, it provides significantly weaker security properties than re-running EDHOC with ephemeral Diffie-Hellman.  Even with frequent use of KeyUpdate, compromise of one session key compromises all future session keys, and an attacker therefore only needs to perform static key exfiltration RFC7624.  Frequently re-running EDHOC with ephemeral Diffie-Hellman forces attackers to perform dynamic key exfiltration instead of static key exfiltration RFC7624.  In the dynamic case, the attacker must have continuous interactions with the collaborator, which is more complicated and has a higher risk profile than the static case. To limit the effect of breaches, it is important to limit the use of symmetrical group keys for bootstrapping.  EDHOC therefore strives to make the additional cost of using raw public keys and self-signed certificates as small as possible.  Raw public keys and self-signed certificates are not a replacement for a public key infrastructure but SHOULD be used instead of symmetrical group keys for bootstrapping. </ins> Compromise of the long-term keys (private signature or static DH keys) does not compromise the security of completed EDHOC exchanges.

integrity is provided by the inner MAC (and signature depending on method). <del> The data rates in many IoT deployments are very limited.  Given that the application keys are protected as well as the long-term authentication keys they can often be used for years or even decades before the cryptographic limits are reached.  If the application keys established through EDHOC need to be renewed, the communicating parties can derive application keys with other labels or run EDHOC again. </del> Requirement for how to securely generate, validate, and process the ephemeral public keys depend on the elliptic curve.  For X25519 and X448, the requirements are defined in RFC7748.  For secp256r1,