On Mon, Jan 13, 2025 at 12:10:41PM +0100, Rasmus Dahlberg wrote:
On Mon, Jan 13, 2025 at 10:49:00AM +0100, Simon Josefsson wrote:
Thanks for help!
Niels Möller via Sigsum-general sigsum-general@lists.sigsum.org writes:
Simon Josefsson simon@josefsson.org writes:
Do you have any objection to the following text snippet? What could you suggest as improvement? I picked 5 AW witnesses from your list.
Ask Al on IRC/Matrix for how he'd recommend to trim down the policy. He's one of the people that are reponsible for the armory witnesses.
It's a bit unclear to me what reliability to expect from the AW witnesses, but it makes sense to me as a starting point.
And as usual, availability of logs and witnesses matters at the time that you need to make a new release. It doesn't matter at all at verificatino time, since that's offline.
So then shouldn't my trust policy be 'all' rather than a 3/5 setup? Assuming all of witnesses are online when doing 'sigsum-submit' as part of the release. I used a 'group ... 3 ...' statement now.
I think of the policy as more long lived. If you "all" now and the next time one witness is missing, then you can't release for an "all" policy.
Maybe with a somewhat more verbose name for the GTF group (I guess it's an abbreviation for google trust fabric, but I guess that's unobvious to users).
Does it convey anything meaningful to the user? I prefer avoiding avoidable advertising.
It says something about what you think Sigsum banks on to be a secure system of append-only log(s). Probably useful for some but not others.
Wouldn't it be more reliable to include two different logs, possibly
It's more reliable from an availability perspective. I.e., it is sufficient that any of the logs are online when you do a submission.
with 2/3 witnesses each? Having a single point of control on the 'seasalp.glasklar.is' domain name seems like a serious problem to me. Hard-coding IP addresses? Tor onion name?
For those wanting a Tor onion name, it's on Linus' TODO list.
https://git.glasklar.is/glasklar/services/sigsum-logs/-/issues/26
It would be good to have additional logs, for reliability. But as far as I'm aware, for now seasalp is the only available one with any intention to operate reliably.
How hard is it to operate? Maybe I could set one up too, for experimentation...
Not hard, a few pointers to get started:
https://git.glasklar.is/sigsum/admin/ansible/-/tree/main/roles/litewitness https://github.com/FiloSottile/litetlog?tab=readme-ov-file#litewitness
Oh wait, I thought you meant witness. Logs are more work.
-Rasmus
Adding a tor onion address is certainly doable, but it's not entirely clear to me what benefits you get; the log is authenticated using its key, so what you'd protect against is attacks on the DNS lookup or attacks on routing or ip-based filtering somewhere in the middle of the routing path?
Perhaps I was just confused -- maybe the DNS name is not looked up during verification? I was worried about that DNS name going away.
Correct -- if the trust policy is only meant to be used by sigsum-verify you should be able to remove the log URL all together. At least it looks like this would be a valid policy when reading the example here:
https://git.glasklar.is/sigsum/core/sigsum-go/-/blob/main/doc/policy.md?ref_...
Can I specify a quorum group requiring inclusion into two different logs with one witness each? Is there an example of a trust policy with multiple logs, and multiple witness from each, and some quorum setting? Can one witness validate multiple logs?
When adding multiple logs to the policy, the semantics is that any of them is fine. Verifier accepts any of them, submitters submit to a randomly selected available log, and monitors should monitor *all* the listed logs.
And the expectation is that you would have more or less the same set of witnesses cosigning all logs in your policy. We'll put that to the test for the next log that someone wants top operate, and which we'd then like to be witnessed by both AW and by the glasklar witness that should materialize soon.
The same quorum in the policy applies regardless of which log was used. If we used a separate quorum for each log, I think that would make analysis of split view attacks a lot harier.
Okay. Would it meaningful for a client to (be able to) require that something was submitted to two different logs?
No -- the potential security property that you're sketching on here is what the (much lighter) witnesses provide.
-Rasmus