Add timestamped "cosignature/v1" signatures

[FiloSottile]

As we discussed before, it's useful for witness cosignatures to include a timestamp for clients that care about the time interval in which a leaf became available, and for monitors that want to make sure they are not being held back, amongst other things.

This PR introduces a new signing algorithm that signs the following message, and produces a concatenation of the timestamp and the signature. The previous signer is retained for backwards compatibility, so the witness appends both a plain and a timestamped signature (at least for now).

cosignature/v1
time 1679315147
example.com/log
15368405
31JQUq8EyQx5lpqtKRqryJzA+77WD2xmTyuB4uIlXeE=

The cosignature/v1 header is to help domain-separate any future signature algorithm revisions. The time prefix on the second line ensures this message can't be confused with a plain tree head (which will only have decimals on the second line). The rest of the message are the first three lines of the note.

The choice of not signing the extension lines is the part I don't think we had come to consensus on. We discussed it further with the Sigsum folks, and couldn't come up with examples of extensions that would benefit from a "blind consensus" of witness signatures, where the witness is signing but not understanding the extension. If you have any hypothetical examples, it would help greatly with reassessing this. Otherwise, I think the ability to add new signature types like in this PR offers a very smooth and backwards-compatible path to rolling out extensions: logs can start publishing an extension without coordination; then witnesses are updated to parse and validate that extension as appropriate, and to produce both a cosignature/v1 signature and a cosignature/v2 or cosignature/v1+extFoo signature; clients are updated to make use of the extension and check the latter signature.

While at it, I removed the public key command line flag, as it's redundant, and moved the instantiation of the signers inside the omniwitness package as multiple signers can be instantiated from the same private key.

After this PR, Sigsum and OmniWitness trees and witnesses will be fully cryptographically interoperable! (As in, signed and cosigned tree heads can move from one ecosystem to the other, and all witnesses will work with all logs. The APIs are still different, but that's good, I think a diverse set of APIs, CLIs, tools, and tree distribution models are a desirable thing!)

[AlCutter]

/gcbrun

[AlCutter]

We're starting to get a few of these additional note signature algo consts, is there somewhere we could use to keep track of them?

[mhutchinson]

Thanks for this @FiloSottile. I like the idea of the witness helping to set bounds for freshness, but I also have some reservations. I've outlined my main objections below. Please take this in the spirit of healthy, robust discourse, and not "get off my lawn" :-)

The principle behind the witness to date has been simplicity; the only claim a witness makes is that any checkpoint it countersigns will be consistent with any other checkpoints it has countersigned for the same log. Having the witness also claim "...and I signed this one at T" is a small change, but it has some ramifications that I'd like to make sure we're happy with.

Verification of the witness claim

One of the key parts of the claimant model is that claims are falsifiable. I'm not convinced the timestamp claim can be verified. This means there are no checks and balances to make sure that witnesses are reporting the correct time.

TCB

It expands the TCB for witness to potentially include an external party such as its NTP server. This seems an unlikely attack vector, but it does mean that a witness could do something dishonest based on the actions of a new third party. Previously, if the code & toolchain had been audited correctly, breaking the verification claim would have required access to the witness host.

Client code

At the moment clients are using golang.org/x/mod/sumdb/note to create verifiers for notes. Is there a plan to create a library to easily create a cosignature verifier from a verifier key string?

The biggest aid in convincing me of the utility of this would be some client code that uses these witness timestamps to make some decision that it couldn't have made without the timestamps. Are there any examples of such code?

[mhutchinson]

@FiloSottile @AlCutter @haydentherapper @smeiklej and I met yesterday to discuss this. Key points that aren't already clear in this thread are outlined below. Towards the end of this I've included some thoughts I've had since the meeting that weren't brought up in the meeting, so I recommend those tagged take a quick read :-)

Slow down attacks

This attack is applicable in situation where both believers and verifiers talk only to the log to get checkpoints. The log is responsible for collecting and distributing witness signatures to these parties. The attack:

1. Log behaves reasonably for some initial period, with all leaves being valid claims, and sufficiently witnessed checkpoints being distributed to both believers and verifiers
2. For $reasons, log now starts acting maliciously and logs invalid claims. Witnesses only verify the consistency/append-only proof of the Merkle tree (i.e. not leaf data), and thus provide witnessed checkpoints back to the log. The log provides these checkpoints to the believers and can get them to believe invalid claims. Meanwhile, the log does not serve any new checkpoints to verifiers, continuing to show them only the last checkpoint committing to valid claims, with the premise that no new entries have been added to the log.
   • An alternative version of this has the change from good to bad mode done gradually instead of abruptly; the verifiers could still be seeing incremental checkpoints each time they poll, but in reality these checkpoints are being drip-fed and are historic checkpoints being served from a buffer of "good" checkpoints

The proposed solution to the above situation requires two new properties:

1. Witnesses to include the timestamp at which they first saw this checkpoint
2. The log to commit to providing a witnessed (and thus independently timestamped) checkpoint periodically

Thus at any point, the verifier can call out the log for bad behaviour if the most recent checkpoint served by the log does not have a quorum of witnesses showing timestamps fresher than the published period.

What is signed

The current behaviour is to sign the whole note, including extension lines. The proposed behaviour for the new signature algorithm drops signing the extension lines. This means that a witness signature could appear on a note that it had never seen. This is a legitimate feature because the witness is only signing the details that it has verified, so +1 to that.

(The following contains my own thoughts that came after the meeting and thus shouldn't be read as having the same consensus that the above writeup has)

However, there is something that feels a bit weird about this new behaviour:

1. Log gets all of the witnesses to sign a checkpoint that has no extensions
2. Log then constructs two checkpoints; one with extension "BeEvil" and another with "DoNoEvil"
3. It can transfer the witness sigs to both of these checkpoints, and then give the believers the BeEvil version and the verifiers are given the DoNoEvil version

Allowing the log to construct witnessed quorums with arbitrary extension lines feels like a lot of power. OTOH, all clients should realize that witnessed signatures are saying nothing about the extension lines, and thus not trust extension lines. But in this world, is there any benefit at all to extension lines?

If we make the new signature scheme include the whole note (including extension lines) then this takes a significant amount of power away from the log. Witness signatures can only be transferred to identical checkpoints to the one that the witness has seen. Witnesses will only ever sign one checkpoint at a given tree size (and thus can't be tricked into signing multiple checkpoints of the same size with different extension lines), and thus if a quorum of witnesses is reached then the extension line is fixed (i.e. all believers and verifiers must see the same extension data). This encourages logs to use extension lines according to the guidelines given for otherdata here: https://github.com/transparency-dev/formats/blob/main/log/README.md#merging-checkpoints

@FiloSottile would you be persuaded to making the scheme cover all lines in the note? I appreciate that it's less "pure" from a signing perspective, but I think that taking power away from the log to construct arbitrary worldviews is worth it. The other option is to retire otherdata but then this has an impact on the ecosystems that are currently using it such as Sigstore: @haydentherapper

[FiloSottile]

Thank you for the chat and for the recap! Everything in the consensus section looks good to me.

Rosters

Purely for the benefit of future reference, I wanted to record that we discussed an alternative countermeasure to slow-down attacks: rosters. Witnesses publish on a heartbeat a timestamped statement of the largest tree head they saw for each log, and verifiers independently retrieve those documents.

Rosters have a major limitation, to protect an ecosystem where 3-out-of-10 witness signatures are considered valid, verifiers need rosters from at least 8 (M-N+1) witnesses, or they could be partitioned off from the witnesses that signed the hidden tree heads. Especially when we consider how both the N (3) and the M (10) might change over time, this sounds less of a good idea than it did originally. Noticeably, it still requires witnesses to maintain a trustworthy clock.

Other uses for cosignature timestamps

We also discussed believer-side use cases for timestamps, like the ability to place the witnessing time of a claim in a time interval, that can be verified to be within specific bounds, something that rekor needs (c.f. sigstore/rekor#1566).

We could also make a neat Roughtime-equivalent by chaining timestamps in an extension.

Signing extension lines

First of all, I am ok with extending the signature over the whole body as long as we all agree (as I think is the case) that a cosignature/v1 signature makes no semantic statement as to the extension lines. It's just a matter of encoding, and no one wants to diverge over encodings.

However, I want to comment on the BeEvil vs. DoNoEvil behavior. Even if we sign extension lines, in the 3-of-10 witness policy we discussed above, the log can still get 3 signatures over BeEvil, and 3 over DoNoEvil, and serve the former to believers and the latter to verifiers. To avoid that you need more than quorum, you need majority, but I'm very uncomfortable with majority policies. First, they are an availability risk. Second, they require very careful changes over time not to invalidate the security property we just discussed.

Also, a claim in the log is a better place than extension lines for anything that simply needs accountability and not custom witness logic.

But in this world, is there any benefit at all to extension lines?

In the current system, none! They are a backwards-compatible extension point, where we can add in the future—for example—a Roughtime chain, and progressively upgrade the witness, believer, and verifier ecosystems to sign, rely on, and/or verify them, whenever we find something that needs custom witness logic involved.

[AlCutter]

I've rebased this, changed to cover all lines with a comment to make it clear what is meant by the signature (I think that's where we settled from the comments above), and added a bit of test + de-linting.

[codecov]

Codecov Report

Attention: 43 lines in your changes are missing coverage. Please review.

Comparison is base (b7d89e4) 50.74% compared to head (73ada25) 52.37%.

Files	Patch %	Lines
internal/note/note_cosigv1.go	74.07%	20 Missing and 8 partials ⚠️
omniwitness/omniwitness.go	0.00%	15 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #41      +/-   ##
==========================================
+ Coverage   50.74%   52.37%   +1.62%     
==========================================
  Files          12       13       +1     
  Lines        1001     1117     +116     
==========================================
+ Hits          508      585      +77     
- Misses        422      452      +30     
- Partials       71       80       +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[AlCutter]

Added a c'tor for creating a Cosigv1 Verifier from an Ed25519 verifier string too.

[AlCutter]

@FiloSottile

[AlCutter]

@FiloSottile friendly ping - it would be really great to get this functionality integrated with the existing armored witness and distributor deployments before CATS!

[FiloSottile]

Changes look good to me! I'll work on the C2SP specs and with the Sigsum project to align on signing the extension lines. As we discussed, we had a weak preference on that and I think the most important thing at this stage is making progress together.

[AlCutter]

SGTM, 100% - and we'd be very happy to co-author/share "custodianship" of those specs on C2SP BTW.

I'll merge this, although I'll hold off trying to integrate it with the witness network until after CATS now.