Simon Josefsson via Sigsum-general sigsum-general@lists.sigsum.org writes:
I think using a salt opens up for replays or DNS MITMs, which aren't that hard to implement given DNS is not secure.
I think the only benefit of adding such a salt is to make it possible to rotate tokens without also rotating the underlying signing key, and hence enable usage of a more longer-lived key. It won't bring replay protection or any other security benefits.
For replay, I think it's relevant that a leak lets an attacker both use up the legitimate user's quota, and use more log resources than intended, so both user and log has some incentive to not leak the token.
I do sympathise with low complexity here though.
We were thinking that the threat model for the rate-limit mechanism allowed for a simple mechanism without replay-protection. There are ways to do it differently (some variants outlined in the original proposal). If you feel something different is needed, the way forward is a proposal with motivation and some details on the suggested improvement.
I suppose keeping per-client state on the server is a deal breaker?
One way of keeping state on the log server is to explicitly allow-list the users's submit key in the rate limit config; then no other tokens are required.
But I think we want to avoid any more dynamic per-client state.
Could the rate-limiting signature include the signature/message that is intended to be uploaded into the log?
Then the generated token becomes useless after the initial upload. An attacker can only cause the same upload to happen again, which I suppose then is ignored (or is the same signature added to the log twice?).
The log doesn't store duplicate entries, so I think this should work fine.
Regards, /Niels