Key updates not propagating

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Key updates not propagating

Andrew Gallagher
Hi, all.

I extended the expiry on my key (0xfb73e21af1163937) over a week ago and
uploaded it to the pool. I foolishly thought that doing so a few days in
advance of its expiry would be sufficient. Not so. Even today, I see
that many pool members still have not received my new self-sig.

This has caused much disruption on servers that have monkeysphere
configured - logins are still failing at random depending on what pool
server they connect to. Given that dirmngr is a persistent background
process, the DNS round robin doesn't shuffle the pool as fast as you
might think. Clients that hit a bad pool member keep hitting the same
bad pool member until the dirmngr process is restarted. Today I had to
kill dirmngr on one particular server *twice* before it found a good
pool member.

I don't believe this non-propagation is simply a result of bad
connectivity - I can see one "bad" pool member (sks1.cryptokeys.org.za)
is connected directly to the "good" pool server (pgpkeys.urown.net) that
I uploaded my self-sig to. sks1.cryptokeys.org.za has not been correctly
gossiping with *any* of its peers for over a week, and yet remains in
the pool.

Also, to my surprise, one of the high-performance nodes (pgpkeys.hu) is
a "bad" pool member that has not yet discovered my self-sig. I suspect
this is because it is weakly connected to the rest of the pool, and
intermittent gossip failures have left it semi-detached.

All this is an enormous red flashing light.

If the pool members are not mutually well-connected, then uploading a
key (or more importantly, a revocation) to the pool is not a guarantee
that a client that connects to the pool will receive that information in
a timely manner. The basic assumption of a decentralised store of
information is broken.

I have not been running a keyserver myself since the first poison-key
incident. Given the ongoing poison-key problems I am unlikely now to
ever run one again, unless the entire codebase is overhauled. I have
neither the time, energy nor skillset to perform this task, and it is
becoming clear that nobody else does either.

This is not anyone's fault. It is just an unfortunate reality that we
have to accept. SKS is end-of-life.

WKD is a useful and simple tool for finding keys that match email
addresses. We do not need the keyservers for this any more. What WKD
does not provide is twofold:

1. A way to search for keys that do not correspond to email addresses
(e.g. code signing keys)
2. A way to refresh key validity (self-sigs and revocations)

I suggest that we start by solving these two narrow problems.

Might it be possible to replace the keyserver network with a lightweight
URL redirection service? This would remove the requirement for the
keyservers to host any data at all, solving multiple problems in one
stroke. The main disadvantage would be that it would be simple to block
timely distribution of revocations - but right now this isn't happening
anyway.

Thoughts?

--
Andrew Gallagher


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Key updates not propagating

Yegor Timoshenko
> This is not anyone's fault. It is just an unfortunate reality
> that we have to accept. SKS is end-of-life.
>
> WKD is a useful and simple tool for finding keys that match
> email addresses. [...]
>
> Thoughts?

Hagrid is a verifying, validating keyserver that implements
subset of HKP: https://gitlab.com/sequoia-pgp/hagrid

Despite effectively being centralized, I believe that it provides
better censorship resistance than today's SKS. Given that it's
reverse compatible with GPG's `--recv`, I think it is a good
migration strategy, until something that correctly tackles the
problem of untrusted, uncensorable, verifying decentralized key
storage comes out.
_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Key updates not propagating

Alain Wolf-2
In reply to this post by Andrew Gallagher
Hi Andrew

Am 18.01.19 um 13:05 schrieb Andrew Gallagher:

> Hi, all.
>
> I extended the expiry on my key (0xfb73e21af1163937) over a week ago and
> uploaded it to the pool. I foolishly thought that doing so a few days in
> advance of its expiry would be sufficient. Not so. Even today, I see
> that many pool members still have not received my new self-sig.
>
> This has caused much disruption on servers that have monkeysphere
> configured - logins are still failing at random depending on what pool
> server they connect to. Given that dirmngr is a persistent background
> process, the DNS round robin doesn't shuffle the pool as fast as you
> might think. Clients that hit a bad pool member keep hitting the same
> bad pool member until the dirmngr process is restarted. Today I had to
> kill dirmngr on one particular server *twice* before it found a good
> pool member.
>
> I don't believe this non-propagation is simply a result of bad
> connectivity - I can see one "bad" pool member (sks1.cryptokeys.org.za)
> is connected directly to the "good" pool server (pgpkeys.urown.net) that
> I uploaded my self-sig to. sks1.cryptokeys.org.za has not been correctly
> gossiping with *any* of its peers for over a week, and yet remains in
> the pool.
While sks1.cryptokeys.org.za is listing pgpkeys.urown.net as peer. It
is not cross-peered back by pgpkeys.urown.net.

>
> Also, to my surprise, one of the high-performance nodes (pgpkeys.hu) is
> a "bad" pool member that has not yet discovered my self-sig. I suspect
> this is because it is weakly connected to the rest of the pool, and
> intermittent gossip failures have left it semi-detached.
>
> All this is an enormous red flashing light.
>
> If the pool members are not mutually well-connected, then uploading a
> key (or more importantly, a revocation) to the pool is not a guarantee
> that a client that connects to the pool will receive that information in
> a timely manner. The basic assumption of a decentralised store of
> information is broken.
>
> I have not been running a keyserver myself since the first poison-key
> incident. Given the ongoing poison-key problems I am unlikely now to
> ever run one again, unless the entire codebase is overhauled. I have
> neither the time, energy nor skillset to perform this task, and it is
> becoming clear that nobody else does either.
>
> This is not anyone's fault. It is just an unfortunate reality that we
> have to accept. SKS is end-of-life.
>
> WKD is a useful and simple tool for finding keys that match email
> addresses. We do not need the keyservers for this any more. What WKD
> does not provide is twofold:
>
> 1. A way to search for keys that do not correspond to email addresses
> (e.g. code signing keys)
> 2. A way to refresh key validity (self-sigs and revocations)
>
> I suggest that we start by solving these two narrow problems.
>
> Might it be possible to replace the keyserver network with a lightweight
> URL redirection service? This would remove the requirement for the
> keyservers to host any data at all, solving multiple problems in one
> stroke. The main disadvantage would be that it would be simple to block
> timely distribution of revocations - but right now this isn't happening
> anyway.
>
> Thoughts?
>
>
Regards

--
pgpkeys.urown.net 11370 # <[hidden email]> 0x27A69FC9A1744242


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Key updates not propagating

Andrew Gallagher

> On 18 Jan 2019, at 17:47, Alain Wolf <[hidden email]> wrote:
>
> While sks1.cryptokeys.org.za is listing pgpkeys.urown.net as peer. It
> is not cross-peered back by pgpkeys.urown.net.

Of course. Please don’t take anything I say as an accusation against either yourself or any other particular keyserver operator. These things happen (I was a less than exemplary pool member for several years!). The problem is not that there are keyservers that don’t gossip efficiently with peers, but that weakly connected keyservers can remain in the pool regardless.

A

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Key updates not propagating

H Visage
Yes,

 With the poison key issues that started last year, I have neglected the  cryptokeys.(co|org|net).za instances ;(

I fear I need to reload DBs on them, which unfortunately takes human time and effort, and then the single threaded nature of the SKS software
then fails on the next problem key, pull down the service (running on not the fastest VPS instances), and we have again a “weakly connected” case… it’s not the connectedness that is the issue(s), but the SKS software that fails and needs lots of TLC to get going again.

No offense taken, though duly noted I need to schedule time and effort on them again ;(

On 19 Jan. 2019, at 00:55 , Andrew Gallagher <[hidden email]> wrote:


On 18 Jan 2019, at 17:47, Alain Wolf <[hidden email]> wrote:

While sks1.cryptokeys.org.za is listing pgpkeys.urown.net as peer. It
is not cross-peered back by pgpkeys.urown.net.

Of course. Please don’t take anything I say as an accusation against either yourself or any other particular keyserver operator. These things happen (I was a less than exemplary pool member for several years!). The problem is not that there are keyservers that don’t gossip efficiently with peers, but that weakly connected keyservers can remain in the pool regardless.

A

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel




---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
+27-84-612-5345 or +27-21-945-1192
[hidden email]




_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (499 bytes) Download Attachment