core-wg / oscore-key-update

Other
0 stars 0 forks source link

Negotiating non-forward-secrecy: Can this be static? #54

Closed chrysn closed 1 year ago

chrysn commented 1 year ago

KUDOS is run on a single key shared by two parties, and AIU whether or not KUDOS can be used is a piece of information that is placed into an OSCORE node along with the algorithm, the IDs, the key material and the window size (which currently no key establishment method bothered to allow changing).

If that is correct, maybe we can do away with the run-time negotiation of whether or not to use PFS mode, and whatever tells the node that KUDOS is allowed here, that negotiation could also produce the variant of KUDOS (whether it is with or without PFS) as an output.

This would remove a piece of runtime complexity, in particular removing code paths I expect to receive very little testing.

(And by the way, what is the default of whether or not KUDOS is supported when OSCORE is negotiated from EDHOC? What if the OSCORE key comes from ACE-OSCORE? Maybe the EAD item could phrase the information in a similar way as the ACE CWT does).

rikard-sics commented 1 year ago

From discussions during the CoRE interim on September 28 it seems good to keep the "negotiation". This is because we then do not assume any pre-knowledge. The peers can find out if each other supports KUDOS, and also in what mode. (Of course any pre-knowledge available can be taken advantage of, but it is a strong assumption and restriction to force them to have this pre-knowledge).