Re: [Trans] Gossip draft CFA closed

[Bryan Ford <[e-mail]>]

Hi Tom, finally following up on your E-mail long-ago:

On 13 Aug 2015, at 02:44, Tom Ritter <[e-mail]> wrote:
> I think that even if every log had a 51 of 100 signers threshold
> scheme, we would still want some form of verification that logs are
> operating non-maliciously. While the bar for collusion or compromise
> is higher (at 51 instead of 1), the minimum and average technical
> operating level for the signers of 3 such multi-signer logs will be
> much lower than that of 3 single-signer logs. While each signer can
> act as an auditor _for the data it sees_, there is no guarantee that a
> signer might not be presented with a split-view of the log and never
> be able to catch the other signers acting on the other side of the
> merkle tree.  So I still think verification is needed.  And that
> verification would probably look something like gossip….

The intent of my proposal is that the log-server operator (or anyone operating a public authority service with a cloud of co-signing witnesses) choose witness/co-signing servers from reputable (but independent) organisations competent enough to keep their witness servers up and available almost all the time.  (Surely there must be 100 organisations out there who can keep a server running, especially one that’s trivial to replicate…)  

Thus, in the intended operating mode I would hope and expect it to be rare for even one co-signer to be missing.  If many co-signers are missing it should mean either (a) the Internet is in the midst of a major connectivity meltdown and might have more urgent problems than issuing new certificates or STHs; or (b) the primary signer (e.g., log server) itself is disconnected from the rest of the world, in which case no one is going to hear about any new STHs it signs promptly anyway until it reconnects, so maybe it would actually be better if it just waits until it reconnects to the world.

If a co-signing witness is persistently unreliable, it should be kicked out of the group at the next opportunity.

> Whenever I've seen someone propose something to the effect of "And a
> different organization will be responsible for the uptime of your
> organization!" it tends not to get traction. So I'm skeptical that a
> multi-signer approach can be practically deployed. But I would love to
> be proven wrong.

Agreed, that’s an important issue, but as mentioned in my immediately prior E-mail to Ben that’s not a problem here.  The primary signer (log server) can forge ahead using any threshold it wants, including a threshold of 0 if it wants no risk at all of its progress being blocked by co-signers - but the precise set of co-signers that were or weren’t present in a round are precisely documented in the collective signature (and in the current mechanism, must be available to clients for signature verification.)

If many (e.g., O(N)) co-signers are missing from a given round, then the collective signature grows and its verification cost likewise grows to be comparable to the simple case of simply collecting O(N) individual signatures.  But again the intended operating principle is that missing co-signers should be rare - or booted from the group if not - and in that case the collective signatures should “almost always” be small and quick to verify.

B

> 
> -tom