Draft: draft-ietf-lake-edhoc

Commentary: Should be checked for conflicts with 
 I think fixing the comments above resolves conflict with , so can then be replaced by this . 
 This proposal for update in the key derivation description also addresses the clarifications requested in , thus replacing . We merge this to include it in -15 and enable further reviews . 
 This is not correct . How to derive and store PRKexporter is completely up to the implementation . One can derive PRKexporter everytime  is called . This make it look like PRKout is overwritten . This should be formulated with and like TLS 1.3 or with and or something . How long to save the old keying material ( PRKout , PRKExported , any derived keys ) is likely up to the application . The importand thing is that they need to be deleted to give FS . 
 There was a request from someone that more guidance on the use of KeyUpdate should be expanded . Maybe not clear how you are supposed to alternate KeyUpdate and Exporter to get FS . 
 As you are considering making the KeyUpdate more detailed , I have a general design question . Are there use cases where one would expect Post - Compromise Security ? That is , if one of the participant 's PRK_out is compromised , a successful KeyUpdate mechanism between the two honest parties would heal them and lock out the attacker That is typically what is met by the double ratchet from the Signal app . The classical way to achieve that is roughly to have each party send out for the update fresh DH ephemeral shares , and add the corresponding DH secret inside the key derivation . ( it would of course require more care than that in the details ) 
 I think part of the plan is to make it less detailed and leave some stuff to the implementation / application :) The current KeyUpdate mechanism only gives forward secrecy . If you exchange some nonces and use them as a context you might get protection against an attacker is not monitoring all your traffic . I think details of this should be specified outside of EDHOC like in the OSCORE KeyUpdate draft in the CORE WG . The double ratchet was discussed in LAKE WG at an earlier point . The conclusion was that it to much complexity to specify that as part of EDHOC . To get this kind of security an application has to rerun EDHOC frequently ( like TLS 1.3 ) . Signal uses the Diffie - Hellman ratchet very often which makes it understandable to have on optimized Diffie - Hellman ratchet post - handshake . Contrained use cases of EDHOC can not do Diffie - Hellman as often as Signal so it was determined that requiring rerun of the full EDHOC was the best tradeoff . Should the EDHOC specification say more about the benefits of frequently rerunning Diffie - Hellman ? I do n't remember how much it says . I recently wrote a paragraph about this that was accepted to RFC8446bis . 
 This is not correct . PRKout does not need to be stored . An implementation can derive the application keys directly and never store PRKout . An implementation can also store PRK_exporter if they do n't use EDHOC - KeyUpdate . 
 This is not enough . You need to be sure that the old key is not needed more . 
 I merged which addresses some points raised in this issue . Please review and comment if there is anything missing . 
 No comments received , so I assume this is fine . ( KeyUpdate is now in an appendix . )
Paragraph (version A):
The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf, is
the only secret key shared between Initiator and Responder that needs
to be stored after a successful EDHOC exchange, see m3.  Keys for
applications are derived from PRK_out, see exporter.
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.  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):
where hash_length denotes the output size in bytes of the EDHOC hash
algorithm of the selected cipher suite.
Paragraph (version A):
PRK_exporter MUST be derived anew from PRK_out if EDHOC-KeyUpdate is
used, see keyupdate.
Paragraph (version B):
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 B):
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.  The
Initiator and the Responder also need to cache the old PRK_out until
it has verfied that the other endpoint has the correct new PRK_out.
I-D.ietf-core-oscore-key-update describes key update for OSCORE using
EDHOC-KeyUpdate.
Paragraph (version B):
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.