Updates needed to KeyUpdate text

[emanjon]

PRK_exporter MUST be derived anew from PRK_out if EDHOC-KeyUpdate is used

This is not correct. How to derive and store PRK_exporter is completely up to the implementation. One can derive PRK_exporter everytime Exporter is called.

PRK_out = EDHOC-KDF( PRK_out, 11, context, hash_length )

This make it look like PRK_out is overwritten. This should be formulated with N+1 and N like TLS 1.3 or with OLD and NEW or something. How long to save the old keying material (PRK_out, PRK_Exported, any derived keys) is likely up to the application. The importand thing is that they need to be deleted to give FS.

[emanjon]

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.

[charlie-j]

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)

[emanjon]

As you are considering making the KeyUpdate more detailed,

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 added 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 don't remember how much it says. I recently wrote a paragraph about this that was accepted to RFC8446bis.

[emanjon]

is the only secret key shared between Initiator and Responder that needs to be stored

This is not correct. PRK_out does not need to be stored. An implementation can derive the application keys directly and never store PRK_out. An implementation can also store PRK_exporter if they don't use EDHOC-KeyUpdate.

[emanjon]

cache the old PRK_out until it has verfied that the other endpoint has the correct new PRK_out.

This is not enough. You need to be sure that the old key is not needed more.

[gselander]

I merged #314 which addresses some points raised in this issue. Please review and comment if there is anything missing.

[gselander]

No comments received, so I assume this is fine. (KeyUpdate is now in an appendix.)