Draft: draft-ietf-lake-edhoc

Commentary: Replacing a session key with its hash for forward secrecy as specified with EDHOC - KeyUpdate , can alternatively be defined by the application as is done in  ( draft - core - oscore - key - update ) . For this reason there is no need to recommend EDHOC - KeyUpdate as is done in Section 7 . " Implementations SHOULD support EDHOC - KeyUpdate . " EDHOC - KeyUpdate can useful in other applications but the description should be moved out of the body in the interest of focusing on the core functionality of EDHOC . 
 Discussed in the interim and PR merged .
Paragraph (version A):
The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is
the output of a successful EDHOC exchange.  Keys for applications are
derived from PRK_out, see exporter.  An application using EDHOC-
KeyUpdate needs to store PRK_out.  If EDHOC-KeyUpdate is not used, an
application only needs to store PRK_out or PRK_exporter as long as
EDHOC-Exporter is used.  (Note that the word "store" used here does
not imply that the application has access to the plaintext PRK_out
since that may be reserved for code within a TEE, see impl-cons).
Paragraph (version A):
This section defines EDHOC-Exporter and EDHOC-KeyUpdate in terms of
EDHOC-KDF and PRK_out.
Paragraph (version B):
The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is
the output of a successful EDHOC exchange.  Keys for applications are
derived from PRK_out, see exporter.  For the purpose of using EDHOC-
Exporter, an application only needs to store PRK_out or PRK_exporter.
(Note that the word "store" used here does not imply that the
application has access to the plaintext PRK_out since that may be
reserved for code within a TEE, see impl-cons).
Paragraph (version B):
This section defines EDHOC-Exporter in terms of EDHOC-KDF and
PRK_out.
Paragraph (version A):
where hash_length denotes the output size in bytes of the EDHOC hash
algorithm of the selected cipher suite.  Note that PRK_exporter
changes every time EDHOC-KeyUpdate is used, see keyupdate.
Paragraph (version A):
To provide forward secrecy in an even more efficient way than re-
running EDHOC, EDHOC provides the optional function EDHOC-KeyUpdate.
When EDHOC-KeyUpdate is called, a new PRK_out is calculated as a
"hash" of the old PRK_out using the Expand function as illustrated by
the following pseudocode.  The change of PRK_out causes a change to
PRK_exporter and derived keys using EDHOC-Exporter.
Paragraph (version A):
The EDHOC-KeyUpdate takes a context as input to enable binding of the
updated PRK_out to some event that triggered the keyUpdate.  The
Initiator and the Responder need to agree on the context, which can,
e.g., be a counter or a pseudorandom number such as a hash.  To
provide forward secrecy the old PRK_out and derived keys must be
deleted as soon as they are not needed.  When to delete the old keys
and how to verify that they are not needed is up to the application.
I-D.ietf-core-oscore-key-update describes key update for OSCORE using
EDHOC-KeyUpdate.
Paragraph (version A):
While this key update method provides forward secrecy it does not
give as strong security properties as re-running EDHOC, see security.
Paragraph (version A):
Implementations MUST support the EDHOC-Exporter.  Implementations
SHOULD support EDHOC-KeyUpdate.
Paragraph (version B):
Implementations MUST support the EDHOC-Exporter.
Paragraph (version A):
As required by RFC7258, IETF protocols need to mitigate pervasive
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, 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.
Paragraph (version A):
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.
Paragraph (version B):
As required by RFC7258, IETF protocols need to mitigate pervasive
monitoring when possible.  EDHOC therefore only supports methods with
ephemeral Diffie-Hellman.  This 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.  Frequently re-running EDHOC forces
attackers to perform dynamic key exfiltration where the attacker must
have continuous interactions with the collaborator, which is a
significant complication.
Paragraph (version A):
compromise of all keying material derived with the EDHOC-Exporter
since the last invocation (if any) of the EDHOC-KeyUpdate function.
Paragraph (version B):
compromise of all keying material derived with the EDHOC-Exporter.