Re: emailselfdefense.fsf.org indirectly recommends a proprietary service through a new Enigmail defaults

[Werner Koch]

Hi!

On Tue, 16 Jul 2019 07:43, 321942@gmail.com said:

> describes, changed the default keyserver from the SKS round-robin
> pool, to a *proprietary centralized service* [2], “one of whose

Although I have some concerns with those validating keyservers, like
keys.openpgp.org, it is wrong and unfair to call this one proprietary.
This keyserver is not more proprietary than any other key servers.  In
fact the code is under the AGPL so some may consider this even a benefit
(I have a different view but that is not the topic here).

A problem is the single-point-of-validation (done via mail confirmation)
which puts them in a position like X.509 CAs.  However, in this case
more like CAcert.

BTW, although the SKS keyserver network is distributed, its DNS is under
the control of a single person too.  Thus the default keyserver in GnuPG
has a similar SPoF but in this case the guy running this has quite some
long term credibility.

If Patrick (Enigmail author) wants to use keys.openpgp.org as default he
can of course do that.  In particular in the light of the SKS keyserver
performance problems, we are seeing for a year now, and because Patrick
wants to support older GnuPG versions (which is a bad idea, but that is
again up to him).

Keyservers are actually useless these days and I wish they could go
away.  Looking up key at a keyserver does not give you any indication
that the key belongs to the claimed mail address.  A validating key
server tries to fix this by claiming authority to check the mail.
However, this gets us back into the X.509 centralized world.

What we actually need is a service to distribute revocations.
Distributed keyservers can do this but they need to be fixed to avoid
DoS which makes them righty now unreliable for revocation distribution.
We are actually now at the same problems X.509 CRLs are ahing for many
years.  However, this is not baked into the protocol but we are abale to
fix the problem.  If someone would write a distributed keyserver which
implements crypto to check the self-integrity of the key but does not
try to force users to confirm their mail address with the entity running
the keyserver.

Rough idea for a revocation distributing network: Use N bits of the
fingerprint to distribute keys to 2^N keyservers. Each keyserver is
responsible for that subset of keys and will be replicated worldwide.
This allows to keep on using DNS round-robin as well as Onion-balancing
to check for revocations and maybe even for subkey updates.


Salam-Shalom,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

signature.asc
Description: PGP signature