Re: [Sks-devel] SKS apocalypse mitigation

[Phil Pennock]

On 2018-03-24 at 19:01 +0100, Kristian Fiskerstrand wrote:
> I agree with this as well, UAT generally have very limited value, so if
> we introduce a filter to skip all UATs I'm all fine with making that a
> requirement across severs in sks-keyservers.net pools. That isn't
> something that restricts servers overall, but anyhow...

We can do this without incompatibility-triggering filters and without
flag days.

We have KDB and PTree.  Add a third DB, Filtered.

The Filtered does not store the values, only the keys of things "we
don't want".  Value might record a reason and a date, for debugging.

Treat items in Filtered as part of "what we have" for reconciliation to
find the set difference.  That way you never request them.  Return HTTP
"410 Gone" for attempts to retrieve things which are marked Filtered.
That way clients don't try to authenticate and you just say "that might
have once existed, but no longer does".  Include a custom HTTP header
saying "SKS-Filtered: something".

Then it's a policy change to not accept UATs and to mark them as things
to be filtered out instead, and a clean-up tool to walk the existing DBs
and decide what should be in Filtered.  There will be down-time of some
extent, since SKS doesn't like sharing the DBs.

An SKS version which understands "SKS-Filtered:" headers will add an
entry to its own Filtered DB but _not_ delete stuff already in other
DBs.  It should record "I've seen that some peers are unwilling to
provide this to me, I can mark it as unavailable and include it in the
set of things I won't request in future".

Refusing to delete is a protection against someone finding a loophole
where information about other attributes is returned in response for a
request for one attribute, where a bad peer could delete data on your
server.

You won't be asking through reconciliation for something you already
had, thus the deletion prohibition won't be an issue.  You can probably
default to not allowing upload of anything which is in Filtered.  This
provides a DoS opportunity for someone malicious to try to prevent new
signatures flowing.  *shrug*

Each server can update at its own pace, but the pool definitions can be
changed, to encourage a certain pace.  Servers which continue to not
understand 410/SKS-Filtered: will keep asking for keys, becoming more
and more of a burden on others, so there will be incentive to drop
peering before too long.  But returning 410 should be a fast lookup and
the burden not too heavy, so we can afford to give it a 4-6 month window
of interop.

If you want your keys available, always, then take steps to host the
service which makes them available.  WKD, Finger, just an HTTP server,
something.  (Notably, most of these leave a trail of accountability,
unlike the PGP keyservers).  The SKS flood-fill public pool is living on
borrowed time and is not a strategy for continued availability.  We
keyserver operators are running something as a public good, for public
convenience, not operating critical infrastructure.  Disappearance of
public keyservers would be a major inconvenience, but not a disaster.

-Phil

signature.asc
Description: Digital signature