search

core-wg / oscore-key-update

Other
0 stars 0 forks source link

Allow larger nonce lengths #95

Closed chrysn closed 7 months ago

chrysn commented 10 months ago

KUDOS would be a fine base to do away with a lot of text in deterministic OSCORE (https://gitlab.com/chrysn/core-cachable-oscore/-/issues/38).

Trouble is, we'd need nonces that can be longer than 16 bytes. (16 bytes may be fine, given that a 128bit birthday starts hitting at 2**64 requests, but full hashes are longer). Would it make sense to use CoAP extension nibble semantics on m, where 13 means "+1 byte", 14 means "+2 bytes" and 15 is reserved? (No, >256 byte nonces are absolutlely weird, but implementations will have some limit on nonce length anyway, and it may be a fine recommendation that anything > 12 will rarely be needed except when another implemented spec demands it).

In the interest of outer blockwising, it may be worth considering to send the nonce(s) in the payload (similar to how CoAP-EDHOC does it), but please only consider this if there are better reasons to do it than just this request.

(Note to self: I haven't fully looked into how this would all work precisely; in particular, gotta check whether we can get away with no nonces in the response).

rikard-sics commented 8 months ago

This issue, and related considerations will be raised during the CoRE interim on January 17

rikard-sics commented 7 months ago

This was raised and discussed during the CoRE interim on Jan. 17 with conclusion that for KUDOS we do not need longer nonce sizes.

The proposal from Christian to take advantage of KUDOS functionality for cacheable OSCORE do not rely on longer nonces in KUDOS, as a separate option can still be used for relaying the longer hash values.