On Wed, Mar 05, 2025 at 01:27:17PM +0100, Simon Josefsson wrote:
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?
I think both would work. With a few minutes of thinking I can't think of a good argument for why a full transcript would be better here; but if it is easier to implement and/or describe that might be a decider.
(My thoughts go in the direction of malleability of signatures and whether there's a point in locking down the entire transcript.)
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
Sounds good, thanks for thinking about it!
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.
Let's Encrypt rate-limits on DNS names and IP addresses.
https://letsencrypt.org/docs/rate-limits/
Rate limits on CT logs are (upper) bound by the number of certificates CAs are willing to issue. So, either it is bound by DNS names and IP addresses or it is bound by how much money the attacker spends on certs.
CT logs typically use IP addresses for rate limiting as well.
It would be possible to configure, e.g., seasalp to accept up to a quota of submissions per time unit without any proof of controlling a DNS zone. IP addresses could be used to make it harder for a single party to consume the entire quota. But generally speaking I don't think that achieves much, it's too easy to send requests from many different IPs. And going further down this rabbit hole seems like the wrong direction.
But do let me know if you think it would be useful to allow some submissions to seasalp (global quota that anyone can use). My thinking is that's mainly useful for testing, which is why we have jellyfish.
What I'd be more interested in is other rate-limit approaches than DNS; and which doesn't depend on IP addresses. What I'm looking for is something that's "hard" to get many of, "easy" to get one of, and it is "easy" for a log server to verify that the submitter "has the thing".
When it comes to Let's Encrypt scale, Sigsum is in a better position here since a log only needs to store 128 bytes per submission. Compare this to an entire certificate chain: ~5-6 KiB, ~1-2 KiB assuming dedup.
That said (as you already noted), simply accepting everything from everyone and adding that to append-only storage doesn't work.
It's not at the top of my list to find alternative ways to do rate limiting, but it's in the back of my head to think about the options.
I'd be more than happy to hear about your ideas in this space!
-Rasmus