Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?

[Andrew Gallagher]

On 2019/02/06 23:51, Robert J. Hansen wrote:
> No.  Keyserver reconciliation is 90% of the problem.  Fixing this would
> make it impossible for older keyservers to reconcile with a next-gen design.

I have had a long think about this problem, and I reckon that the
biggest bar to progress is the assumption that arbitrary members of the
pool will upgrade to the new software at random, and that we need to
ensure that all nodes stay synchronised with each other no matter what
version they run, in a single mixed-version network.

We can simplify this problem considerably.

Instead of an operator upgrading their sks server to "new-sks" and
expecting to still be able to peer with traditional sks servers, they
should install the "new-sks" software *in parallel* with the traditional
one (on the same or a different machine, doesn't matter) and this
"new-sks" node should only be able to peer with other "new-sks" nodes.
This means that our new recon protocol can be efficient, because it
doesn't have to keep a record of blacklisted hashes.

If we further assume that key material does not flow back from the
"new-sks" network to the old one, then we can write a relatively simple
cron job that finds updated keys on an old-style sks server (by parsing
its logs, for example) and copies them (suitably censored) to the
corresponding "new-sks" server. At some point, when the "new-sks"
network is sufficiently stable, the pools are redefined and the old sks
network becomes irrelevant.

The above allows us to ignore broad categories of problematic material
by policy, simply by defining a narrow set of allowed packets in the new
protocol. Any compliant "new-sks" server will simply not be capable of
processing packets of unapproved types, e.g. image IDs, 3rd party
signatures, and keys with invalid self-sigs. Also, any peer that tries
to serve too many unapproved packets via recon can be twitted.

What the above will not do is allow individual operators to blacklist
arbitrary packets by hash, not without either some central authority
defining a shared blacklist, or a fake-recon process that maintains
local blacklist caches and runs the risk of split-brain. So the threat
of shutdown by court order is not completely removed.

I still think this may be enough to be getting started with.

A

signature.asc
Description: OpenPGP digital signature