Re: [core] KUDOS, PFS and operations considerations

[Göran Selander <[e-mail]>]

Hi Christian,

Thanks for raising this point.

> This is a conflict between two goals (provide PFS and enable stateless operation) ...

I suppose the constraint to keep the overhead down also come in here.

> ... that I currently see no easy way out of (other than introducing variants for either into the protocol)

That is something worth exploring in parallel to trying to find an common solution.

In combination with the change of connection IDs, this is now starting to warrant a breakout session.

Göran


From: core <[e-mail]> on behalf of Christian Amsüss <[e-mail]>
Date: Wednesday, 17 November 2021 at 19:08
To: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [core] KUDOS, PFS and operations considerations
Hello KUDOS authors,

looking through the current state of KUDOS (compared to earlier
discussions, and prompted by the trackability discussion coming out of
EDHOC), I noticed that KUDOS nowadays discards old key material.

This is nice in that it ensures that old conversations can not be
deciphered from key material obtained from one of the participants
later, but raises operational concerns, especially aiming to replace
B.2:

OSCORE keys are notoriously difficult to back up (or distribute for high
reliability); in that, they behave like the stateful signing keys of
HSS/LMS. A backup can only be done if the backup is replaced before the
sequence number reaches a committed point (eventually stopping the
running system if the backup system fails). For a distributed JRC, this
is about as hard as persisting the mapping between old and new ID
Context values.

On embedded implementations, using OSCORE requires a device that starts
up to commit something to flash memory after startup, which is an
operation preferably avoided.

Appendix B.2 provides a way out of this -- a device that doesn't want
persistent commitment would just always do B.2 on startup and thus
always start sequence numbers from 0. KUDOS as currently described helps
a bit here (in that the first request can be sent without flash
operations), but then requires persisting CTX_NEW and removing CTX_OLD.
The new context needs to be persisted at latest before sending any
second request, because if it's not, the peer may drop the old context
and they have no chance of syncing again. Thus, it's not really helping
to circumvent that impracticality.


This is a conflict between two goals (provide PFS and enable stateless
operation) that I currently see no easy way out of (other than
introducing variants for either into the protocol) -- do you?

BR
c

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom