[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lying about Hockeypuck being SKS?
From: |
Andrew Gallagher |
Subject: |
Re: Lying about Hockeypuck being SKS? |
Date: |
Wed, 24 Mar 2021 00:35:36 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 |
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
- Re: Lying about Hockeypuck being SKS?, (continued)
- Re: Lying about Hockeypuck being SKS?, Andreas Puls, 2021/03/22
- Re: Lying about Hockeypuck being SKS?, Marcel Waldvogel, 2021/03/23
- Re: Lying about Hockeypuck being SKS?, Andrew Gallagher, 2021/03/23
- Re: Lying about Hockeypuck being SKS?, Martin Dobrev, 2021/03/23
- Re: Lying about Hockeypuck being SKS?, Ryan Hunt, 2021/03/22
- Re: Lying about Hockeypuck being SKS?, Martin Dobrev, 2021/03/22
- Re: Lying about Hockeypuck being SKS?, Ryan Hunt, 2021/03/22
- Re: Lying about Hockeypuck being SKS?, Ryan Hunt, 2021/03/22
- Re: Lying about Hockeypuck being SKS?,
Andrew Gallagher <=
- Re: Lying about Hockeypuck being SKS?, Philihp Busby, 2021/03/22
- Re: keyserver.dobrev.eu is back running Hockeypuck, Andrew Gallagher, 2021/03/23
- Re: keyserver.dobrev.eu is back running Hockeypuck, Martin Dobrev, 2021/03/23
- Re: keyserver.dobrev.eu is back running Hockeypuck, Andrew Gallagher, 2021/03/23