Check whether non-random nonces are allowed

[chrysn]

Doing some thought experiments I found that there'd be a scenarios in which I'd not use random nonces:

If I'm persisting the context anyway, I can also persist a counter. Then, rather than using a random nonce that needs to be large to avoid collisions, I'll just pull a new number from that counter, and it's just as well not reuse.

(I thought that there'd be two, and a non-CAPABLE host could use a random nonce once and then crank up through numbers, but they can't because once in non-FS mode it's always the boostrap secret, and it has to be that way because otherwise the peer couldn't tell whether we're starting from bootstrap or starting from the last established keys).

From a short grepping I think that there are no normative references to random nonces, but some appear factual rather than informative (eg. "First, the client generates a random value N1"), so it's a bit unclear whether it's allowed. (They're discouraged for sure for privacy reasons, but that may not be as relevant to some applications as it is to others).

[rikard-sics]

Thanks for the feedback. This can be something to explore further. It is also connected to another issue we have, based on a past comment from John: https://github.com/core-wg/oscore-key-update/issues/11

[chrysn]

Oh, sorry for the duplicate; that escaped my search.

[rikard-sics]

This can be raised during the meeting, mentioning the OSCORE profile of ACE that is doing the same thing. However in that draft the security considerations open the door for using counters

[rikard-sics]

Proposal: non-CAPABLE devices MUST use random values, a CAPABLE device SHOULD use random values (but may use counters if it enforces measures to ensure their freshness and accepts the privacy implications).

[rikard-sics]

This was raised during IETF 118. We can go ahead according to the proposal in the previous comment.