search

core-wg / oscore-key-update

Other
0 stars 0 forks source link

non-FS mode: Spell out practical consequences #88

Closed chrysn closed 9 months ago

chrysn commented 12 months ago

I think it's not immediately obvious that from the limitations around non-FS mode it follows that the original OSCORE context can actually not be used at all for encryption.

The text may need some integration and editing, but my idea is in this direction:

A device that forces non-FS mode for lack of storage can usually not encrypt any message with the old context (the exception being devices that can increment a counter but not a key). Those devices will start KUDOS with the first message they send at startup, be it a request or a response.

marco-tiloca-sics commented 12 months ago

Looks good. To complement with more details:

The "original context" CTX_OLD including the Bootstrap Master Secret and Bootstrap Master Salt MUST NOT be used to protect outgoing messages, unless the endpoint uses on a mechanism such as the one defined in Appendix B.1 of RFC 8613 to ultimately prevent the reuse of AEAD (key, nonce) pairs.

Indeed, following a state loss (e.g., due to a reboot), a non-CAPABLE device has to first perform a KUDOS execution in no-FS mode (with either of the workflow) before becoming able again to securely communicate with OSCORE.