Make quorum deterministic?

[bwesterb]

We do not want retries to help the attacker.

[sciros]

There's a retry logic proposal I have written up on the open-mpic-specification here: https://github.com/open-mpic/open-mpic-specification/issues/3 Agreed that some level of determinism is good so that retries can (to a degree) be useful for the issuer but not for an adversary.

[birgelee]

I agree with @sciros In open MPIC we are going with a max-attempts field to govern retries with the following description language:

The maximum number of times validation or CAA checks should be retried as the result of a single API POST request. An implementation may choose to retry with the same or different perspectives each time. It is recommended implementations cap the number of distinct sets of perspectives that will ever validate a particular identifier to avoid adversaries retrying many times in the interest of getting favorable perspective sets.

[SulemanAhmadd]

I believe details about max number of retries is an implementation specific characteristic, not something that the standard should define.

I am not sure if the client will have the right knowledge or confidence to determine if they should go with the same set of perspective or different on retries when given the option. I am leaning towards keeping it deterministic (the client should not have to deal with it) to prevent an adversary creating a false quorum, while maintaining simplicity in design.

A retry by nature means re-doing the same work. I suspect some CAs in the future might use multiple MPIC services as fallback on failures.

[bwesterb]

Perhaps this is a separate issue, but I'd like to discuss why the MPIC service should be the one to retry. An alternative is for the CA to retry the request to the MPIC service.

@SulemanAhmadd wrote

I believe details about max number of retries is an implementation specific characteristic, not something that the standard should define.

It depends how the retry is implemented. If the vantage points change on each try, then it degrades security. If it's deterministic as you assume, then it's less problematic.

[sciros]

It's a question of balancing the value of retries vs not arriving at a "false quorum" as @SulemanAhmadd mentioned.

If each retry uses the same perspectives every time then whether retries are done by the client or by the service makes no difference. If there is actual logic to making retries more useful than that, then I believe it belongs in the service and should be opaque to the client.

The specific retry logic I proposed is discussed here: https://github.com/open-mpic/open-mpic-specification/issues/3 It attempts to maintain determinism while providing some value to retrying corroboration with disjoint sets of perspectives (cohorts). The client does not get to pick what perspectives are in what disjoint set, and there is a small and finite number of such cohorts that would be created.

This is another situation where the two paradigms -- sellf-hosted vs SaaS -- carry different implications about what makes the most sense to do.

I can't assume that a self-hosted perspective will always be operating perfectly. As a result, there can be value to retries for a self-hosted solution, as they could provide feedback on the behavior of individual perspectives while not letting perspectives that are failing for reasons other than BGP Hijacking mislead corroboration (e.g., London AWS Lambda is down for whatever reason), yet still ensure that passing corroboration follows the spirit and letter of the requirements.

[SulemanAhmadd]

Perhaps this is a separate issue, but I'd like to discuss why the MPIC service should be the one to retry. An alternative is for the CA to retry the request to the MPIC service.

My comment assumed we were discussing deterministic retries initiated by the client (CA) in this thread. Client retries and MPIC service internal retries are two separate issues imo.

So for client initiated retries, I think it makes sense to be deterministic on the set of perspectives each time. We dont have to define an upper limit on possible retries in the standard. Need to make sure adversaries cannot trick the MPIC service to choose its favorable perspectives.

For internal MPIC service retries, I feel @sciros approach is a good one. The service can have the ability to choose different 'healthy' perspectives if some run fails with 'non-healthy' perspectives outcomes (where health is determine by some error types that we can define). This keeps choice of perspectives completely opaque and deterministic to the client at least, while still maintaining useful internal retry logic. Keeping it opaque is the key.

Thoughts?