system-transparency / stfe

Trillian personality that implements the Signature Transparency Logging API

This repository has been moved

See https://github.com/sigsum

stfe's Issues

Enforce shard hint

Sharding is described in our design document and API specification. It is currently not enforced, however. Any shard hint is accepted by the log.

Possible steps to enforce sharding:

1. Add shard interval to the log's configuration, see instance.Config.
2. Add shard interval options in the server package.
3. Reject invalid shard hints, e.g., here.

Enforce domain hint

An anti-spam mechanism is briefly described in our design document and API specification. It is currently not enforced, however. As a first step we need to enforce domain hints.

Possible steps to enforce domain hints:

1. Create a DNS package here.
2. Add the created DNS interface here.
3. Reject invalid domain hints here.

Server configuration

All server configuration is done through "go flags", ie command arguments to the program. This is good for configuration settings which last through the lifetime of an invocation of a log instance, ie from launch to Ctrl-C. Examples: --http_endpoint, --key. It's less good for settings that change over time. Example: --witnesses.

Reading a configuration file at start and when receiving, say, SIGHUP, is an alternative.

Implementing a "control port", typically a TCP endpoint, where an administrator can "program" the log instance is another alternative. Such an interface can also be used for diagnostics.

README: Nitpick signature

First bullet list:
"A signature that covers checksum and identifier using the submitter's secret signing key."

(1) I think it would be good to clarify that it is a cryptographic signature, to distinguish from the checksum
(2) The word "covers" is a bit ambiguous. I suggest you clarify what it means in this context.

Add a read-only mode

The process of shutting down a log will likely consist of at least two steps:

1. Stop accepting new logging requests. Serve the final (co)signed tree heads for a while.
2. Take the log offline.

The first step requires some form of read-only mode. For example:

• Disable all write endpoints: add-leaf and add-cosignature.
• Use a StateManager that serves fixed (co)signed tree heads.

For inspiration we can also look at certificate transparency, see CTFE.

Ed25519 clamping behavior

If I recall correctly an Ed25519 signature has 3 bits that should always be zero. What happens if any of the 3 bits are not zero during signature verification? It probably depends on the implementation. I would expect that the signature is rejected. However, a possible behavior that I would not expect is that the three bits are zeroed ("fixed").

We need the signature to be rejected; not fixed. Otherwise it is possible to replay a logged entry several times by enumerating the remaining bit patterns. Replays are bad for the log (overhead). Replays are also bad for the legitimate submitter because it will eat into their rate limit (DoS vector).

It would be great if anyone could:

1. Confirm if I recall correctly. And if so,
2. Confirm if the behavior of crypto/ed25519 is to reject signatures if any of the three bits are set.

After a quick look this might be the place to understand:

https://cs.opensource.google/go/go/+/refs/tags/go1.16.4:src/crypto/ed25519/ed25519.go;l=208

Support rate limits

An anti-spam mechanism is briefly described in our design document and API specification. One part of it is based on DNS, see #8. The other part is to apply rate limits for the respective second-level domain names.

Trillian supports something like this already. Relevant links:

• Package quota
• I think this can be hooked using the charge_to option.

README nitpick: checksum

Some minor nits on the README

The first bullet in the first list: "A checksum that covers something opaque, e.g., an executable binary."

(1) "Covers" is not a well defined word (I think) when it comes to checcksums. I would suggest "represents".
(2) "something opaque" -> "a data item of opaque type"?
(3) "e.g., an executable binary". The twxt before the bullet gives examples that are not executable binaries. This seems like a surprising limitation.

HTTP status 405, no Allow header

When using HTTP GET for a POST endpoint or vice versa, HTTP status code 405 is returned by the server. According to RFC2616 an Allow header MUST be included in the response.