search

movementlabsxyz / MIP

Movement Improvement Proposals
10 stars 11 forks source link

MIP-1: ENTL #1

Open l-monninger opened 3 weeks ago

l-monninger commented 3 weeks ago

Summary

Also includes MD-2 from #2.

andygolay commented 3 weeks ago

Great stuff @l-monninger, really appreciate the formal breakdown of the security logic.

The time delays required for a malicious MLABSO to restart the service, allowing for honest MLABSOs to intervene, seems like it could be effective in practice.

l-monninger commented 3 weeks ago

Great stuff @l-monninger, really appreciate the formal breakdown of the security logic.

The time delays required for a malicious MLABSO to restart the service, allowing for honest MLABSOs to intervene, seems like it could be effective in practice.

I probably should note that the purpose of the APP-OK-CON message is to allow another opportunity for the honest MLABSO to detect someone trying to be dishonest.

This also plays a bit into DOS attacks on the enclave--which because they are internal are not as much of a priority as elsewhere. But, they still deserve their own section.

mzabaluev commented 1 week ago

A practical consideration that I think needs to be mentioned:

A successful nonce synchronization process (except setting the initial nonce) requires shutting down the client's application for the time lock period, otherwise it would thwart the synchronization attempt with APP messages. What are the implications on availability? In the upgrade scenario we have to take the node down for some time anyway, so extending the downtime for the ENTL synchronization period does not change anything in principle.

l-monninger commented 1 week ago

A successful nonce synchronization process (except setting the initial nonce) requires shutting down the client's application for the time lock period, otherwise it would thwart the synchronization attempt with APP messages. What are the implications on availability? In the upgrade scenario we have to take the node down for some time anyway, so extending the downtime for the ENTL synchronization period does not change anything in principle.

Yes, so this essentially just mandates your rolling release strategy is robust. But, in theory, you keep the old version by handing it off to a redundant ENTL instance until otherwise notified. This is closely related to #2 .

I will add notes here.