Simon Josefsson simon@josefsson.org writes:
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 it is desirable if the policy you distribute now can be used to verify your *next* release too. And with "all" you'd get in trouble if one of those witness devices is offline at that time.
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 that the utility of those witnesses (and the policy) depends on Google (the operator(*) of all witnesses in the policy) behaving properly. You could think about that in two ways:
* Either it's unavoidable advertising... since you are endorsing that policy, that implies that you think the policy has some utility, and hence that you want to express some level of trust in the witness operator.
* Or you can think about it as a statement of conditional utility: You say that the policy has utility only for those users willing to have some level of trust in the witness operator doing the right thing.
But in either case, I think it is meaningful for users to know about. And it will clearly be an improvement when we have more production witnesses online.
(*) one could maybe debate whether or not the AW witnesses are "operated" by Google; the devices are operated physically by selected individuals, as I understand it, but both selection of those individuals, and the software updates for the devices, is controlled by the Google folks.
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...
Somewhere strictly between "trivial" and "extraordinary difficult"... For redundancy, you need two machines (and some rough understanding of the fail-over procedures). Each machine needs our log server software + trillian + mysql (we have some ansible stuff to help set that up). And you need to think about how you want to manage the log's private key, there's documentation on how we do that, using multiple yubihsm and physical safes, which is a bit cumbersome and expensive.
If it's for experiments, you can simplify that a bit with a single node and cleartext key on disk (which is how we run poc.sigsum.org/jellyfish). That's still not trivial, but rather easy.
If you are able to operate a production service (say, you're aiming to keep it running for two years, with downtime at most a few days at a time), I think at this time, an additional witness would be more valuable than an additional log.
Perhaps I was just confused -- maybe the DNS name is not looked up during verification? I was worried about that DNS name going away.
It's not needed by the verifier. It is needed by a monitor, which is why I'd suggest you include it in the policy file, even though it's syntactically optional.
Okay. Would it meaningful for a client to (be able to) require that something was submitted to two different logs?
Generally, no. I can see hypothetical scnarios where it could make sense, e.g., if you want to require both group A and group B of witnesses to cosign releases, but those witnesses for some reason don't witness the same logs. Then you could distribute two separate proofs of logging, verify them against separate policies, and require that both proofs are valid. And those semantics would have to be built on top of current tools.
(We might end up with some of those complexities in our tooling, if we want to have multiple versions of policies, which policy to apply depending on the time the proof was made, or by which submission key, but that's still all very open).
Regards, /Niels