Properly sanity check aggregator/calendar responses

[petertodd]

Currently the only sanity check that RemoteCalendar does is to reject responses larger than 10KB.

For submission, we should verify/filter the following:

• [ ] PendingAttestation matches expected whitelist (URL is unauthenticated!)
• [ ] Number of PendingAttestation's is reasonable
• [ ] Hash operations are sane (exclusively SHA256?)
• [ ] Proof size is appropriate for merkle tree aggregation
• [ ] All attestations are known (maybe not a good idea for upgradability? e.g. a future trusted signature scheme could return valid attestations directly in response to a submission)

And when getting timestamps:

• [ ] Response does not include any PendingAttestation's (allowing loops greatly complicates the logic)
• [ ] Redundant attestations (e.g. two different bitcoin blocks)

[cloutier]

We could have clients fetch block headers from calendars (and potentially other sources), and then save only the chain with the biggest cumulative proof-of-work. The response could then be validated against that. Block headers are small and easy to cache (both client and server side).

This would make most (all?) pentential errors and attack very expensive to get away with, and no further sanity check would be needed.

I'm not proposing this for the actual timestamp verification, just as a thorough validation on upgrade. Doing otherwise feels like moving the problem, because we wouldn't know if the headers are from valid block, and trying to track consensus from this library feels like a really bad idea.

[petertodd]

@cloutier I'm talking about a different type of attack actually - nuisance attacks that make timestamps bigger than necessary, or try to exploit bugs in validation logic.

But yes, when getting timestamps for upgrades it's definitely worthwhile to verify them if possible! :) I'd like to just solve this once, with a reasonably secure semi-trusted lite client mode; I have a few ideas for that already.

[cloutier]

@petertodd Oh, thanks for the clarification!

Completely aggreed for the restricting the rules to avoid potential holes. However, how do you define bigger than necessary, especially in periods of high demand for timestamps?

[petertodd]

@cloutier For example, even though a merkle tree proof shouldn't be more than about 1KB of data, the current codebase will accept up to 10KB of data; remember that proof size should be logarithmic with the number of timestamps as it's a merkle tree.