On Mon, Mar 03, 2025 at 10:42:40AM +0100, Sigsum General wrote:
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?
Correct -- that's something we would like to avoid.
Could the rate-limiting signature include the signature/message that is intended to be uploaded into the log?
It could, yes. I think there are two variations:
1. Binds only to the message 2. Binds to the message and the log.
(1) would allow the log operator to replay the message in a different log. Probably not a big deal in practise, but also seems not great.
(2) prevents such replays, but implementation on the client-side increases slightly since a new signature is needed if, e.g., sigsum-submit tries to submit to log A and then fails over to log B.
Implementation wise I think (2) would be OK, but it's nice if it's easy to tell the user how many signatures will be needed. E.g., so that they know they would be expected to click a hardware token, say, 3 times.
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?).
Correct -- byte-identical entries will not be added multiple times.
Or sign a timestamp, and the server require it to be fresh and within 5 minutes of current time?
This would also work. The hard part is tuning the time T, but if we assume that the rate limit key pair is always available on the online machine (which seems reasonable) I think 5m is in the right ballpark.
Complexity wise I think it's in the same ballpark as what we have now.
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.
I agree there's room for improvement; and from the top of my head it sounds like you have two ideas that are worth cosindering. If I had to pick one approach I prefer more, then it would be to use timestamps.
Note that it's relatively easy to extend
https://git.glasklar.is/sigsum/project/documentation/-/blob/main/log.md#4--r...
with an additional rate-limit approach. If it strictly superseeds what we had before in every way, then I would expect that the old way can eventually be deprecated. (But it wouldn't be a lot of complexity for the log-go implementation to just support two different HTTP headers.)
Tooling wise--sigsum-submit--it would also be easy to just start using the new approach underneath the hood. Because passing tokens directly to sigsum-submit is not supported (we're only doing that in our CI).
As nisse said, a proposal would be great if you'd like to help move anything towards decision. Otherwise I think we should open an issue in
https://git.glasklar.is/sigsum/project/documentation
that describes the gist of the ideas with a link to this email thread, i.e., so that someone remembers to circle back to it at a later time.
-Rasmus