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
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel