Re: Lying about Hockeypuck being SKS?

[Andrew Gallagher]

On 22/03/2021 22:02, Ryan Hunt wrote:
> However I’d like to see some efforts made towards:
>   - Rolling our SKS hacks back upstream with HP, initially this seems 
> stupid but HP has already put in efforts to maintain compatibility with 
> SKS peers.. I think a transitional SKS emulation mode that is easy to 
> implement and maintain upstream is worthwhile, especially if we can come 
> up with a plan to deprecate this nonsense down the road and its just to 
> get us through the near future.

There is still a lot of traffic coming in to the pool, and it's become a 
running theme in the PGP space to have archaic software still in 
production use. However even when there were only three nodes in the 
pool earlier today, pgpkeys.eu didn't break a sweat serving its share.

There is a strong argument that it is better to break things entirely so 
that people still using old software don't have a false sense of 
security. But I really dislike the idea of breaking things without 
building the replacement first.

> I’m thinking like a dedicated machine readable status/health 
> API endpoint that the server can sign with its own key and the pool 
> provider can verify its the server it claims to be, and make 
> accommodations for blacklisted/removed keys/max key sizes/etc accounting 
> for variations in key counts.

+1

> TBH I think creating our own pool is likely our best option going 
> forward, yeah it’ll take some time (ie years) before Distros and the 
> various PGP clients come back.. but most of em that I used personally 
> that came out the box w/the SKS pool no longer do so I think the damage 
> has long been done.

I think the idea of a self-organising pool has some fundamental flaws. 
As was pointed out in another thread, it would be relatively easy for a 
malefactor to set up a few new pool nodes and then artificially inflate 
their key count in order to exclude honest operators. Even as an 
otherwise well-behaved member, it's possible for an operator to gather a 
log of IP addresses vs keys searched, in order to build a contacts graph 
(for the record, pgpkeys.eu permanently deletes its logs on a short 
cycle, currently <=48h and likely to decrease in the near future).

Tor is one way to address this, but it is not suitable for everyone. So 
running a keyserver comes with a requirement of trust and reputation, 
because privacy and security are not the same thing, and must sometimes 
be balanced.

My own view of the medium-term future is that there will be a diversity 
of keyserver operators that will not agree on everything (e.g. policy 
blacklists, data retention) and we have to find a way to coexist. The 
SKS pool structure is based on the assumption that there is one notional 
"complete" (if time-dependent) dataset, and all keyservers will tend to 
converge towards it. That was always a fragile assumption, and we should 
be working to make it unnecessary, so that individual operators can 
choose to what extent they wish to stay in sync with others.

Currently, we have a number of disconnected "big" keyserver operators 
(keys.openpgp.org, mailvelope, keybase, ubuntu...), but I don't believe 
it is user-friendly to expect non-experts to worry about which 
keyservers to publish to or fetch from. I hope to see them all back in 
communion with each other, even if only to distribute the bare minimum 
such as key revocations. This will by necessity have to be an open (and 
preferably well-defined) protocol, and it would be nice to have two or 
three independent implementations, but one step at a time.

So I suspect we'll end up with something more akin to DNS, where there 
are a smaller number of "root" servers, and then individual 
organisations can set up their own instances that field internal 
requests (thereby minimising behaviour leakage) but also sync with the 
roots. Individual users can choose to talk to whichever keyserver has 
the best reputation, rather than relying on a random pool member to be 
an honest one.

--
Andrew Gallagher

OpenPGP_signature
Description: OpenPGP digital signature