Describe cryptographic issues with V when scaling it

[mcr]

No description provided.

[gselander]

(I assume the new changes in this PR are only rows 717-775? The remaining changes looks inherited from other PRs.)

Does the new update which makes V stateless (PR #18) have an impact here? What are the scalability issues if message_1 is not stored until received from W?

In that context, I suppose that V could optionally rate limit new message_1 from U depending on outstanding EDHOC runs where message_1 passed on to W but not returned.

[mcr]

Sorry, the diff is hard to read because it was rebased upon the underscore change.
It would be fine if message_1 is removed from V's database after being sent to W. That retains some of the stateless of the system.

[gselander]

OK. But you still want to store message_1 to the database when it arrives from U? (It isn't it sufficient to read out LOC_W, encode state and forward to W?)

[mcr]

Vs can't speak to W (or maybe not the Internet at all), only to the database (and Pledge).
Vn can't speak to V, only to the database (and The Internet).

[gselander]

OK. Then should just mention the removal of message_1 from the database after being sent over Vn.

What does this mean for secure storage for private key of CRED_V and secure execution environment for PoP? If Vs has secure storage/execution, then it can do PoP against U but not against W, and v.v. for Vn, but we require PoP to be done against both U and W for the same key.

[gselander]

If we don't have the time to address this soon, I propose we wait with merging this part.