Niels Möller via Sigsum-general sigsum-general@lists.sigsum.org writes:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
The risk: if $token is somehow revealed to an unauthorized party, then that party can start spending your rate-limit. Recovery requires rotating the rate-limit key and updating your DNS TXT record. In which case you're back to having separate keys.
One could improve this by adding a salt to the DNS record, and have the signature cover salt + log's pubkey. Then tokens could be rotated by changing only the salt. This was discussed back then, see https://git.glasklar.is/sigsum/project/documentation/-/blob/main/proposals/2...,
Not entirely sure why we rejected this extension at the time, we probably did it in order to keep things simple, under the theory that it's fine to use a separate lower-security key for the rate limits.
But we could reconsider, if it makes things easier for Sigsum users.
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 do sympathise with low complexity here though. I suppose keeping per-client state on the server is a deal breaker?
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?).
Or sign a timestamp, and the server require it to be fresh and within 5 minutes of current time?
Both these approaches require no additional state to be kept on the server for validating the rate-limiting token.
The advantage is that it allows reduction of additional private key life-cycle management for the clients.
Of course, clients should be PERMITTED to use a separate rate-limiting private key if they so prefer. But they could be PERMITTED to use the same private-key used for signing content also for the rate-limiting statements. This is already possible now, but the method to generate the rate-limiting Token seems more fragile than it could be. So there is room for improvement.
/Simon