Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
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:
- Binds only to the message
- 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.
Agreed - binding to message and log seems good. Comparing this to other situations, maybe the signature should be a "full transcript" signature of the upload request which presumably includes both message signature and log identity?
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.
I'll think about this some more -- I had an initial reaction that the assumption to require control of some DNS zone to insert the public key of the rate-limiting signature is a serious problem.
I would prefer if people without control of a DNS zone could insert things into the Sigsum log.
I suppose it is not possible to design the server to scale to arbitrary loads, limited by network bandwidth? I'm thinking Letsencrypt-levels of requests, they must have similar challanges about rate limiting.
/Simon