rikard-sics
commented
2 weeks ago Thanks for the feedback!
Our goal was to always start with the highest security level possible, so typically using FS-mode. Then peers can potentially agree on a downgrade to no-FS mode, only if necessary (one peer is non-CAPABLE). The rationale behind this is to allow devices to learn what the other party supports.
For instance, if I know that my fellow peer B supports FS mode I will consistently use that mode with them. So our idea was that the possible transitions between FS and no FS-mode is very limited, that is only in one direction FS->no-FS and that such a transition can only happen once and then be permanent. If we allow also upgrades from no-FS to FS mode, the learning will no longer be possible.
With regards to your point about the benefit of using shorter nonces, our intent there is that even in the case that the nonces are counters the recommendation to use 8 byte nonces still holds.
Considering these points I close this issue. However we can definitely discuss this further if you wish.
It's not fully thought through, but you can probably do that better than I can if it seems worthy to you (and I urge you to consider benefits before sinking much time here):
Would it be possible to do FS steps after a non-FS?
When things start up, one device forces non-FS on the first KUDOS run (which, as per #88, is the first message exchanged). As per the rules of non-FS, things start from the bootstrap secret. But when then a request to do KUDOS is protected with a secret that is already not the bootstrap secret any more, could that use FS mode, and build on the previously established secret rather than on bootstrap?
That combination would not achieve full FS, for a device that is captured can, in combination with the full captured traffic, be used to decrypt all the traffic. But the combined mode would mean that the captured traffic needs to include all the KUDOS runs between the use of the startup secret and the message to be decoded, and not just the last KUDOS run before the message.
Apart from increasing the amount of data needed to decrypt a message, this also has the benefit that all but the first KUDOS runs can use the short counter nonces mentioned in #89. [edit: Note one only gets one of the two benefits -- counting nonces mean that a captured device can again be used to decode traffic even if KUDOS runs were missed in the data log].