[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emailselfdefense.fsf.org indirectly recommends a proprietary service
Re: emailselfdefense.fsf.org indirectly recommends a proprietary service through a new Enigmail defaults
Wed, 17 Jul 2019 14:37:21 +0300
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
Werner Koch <email@example.com> wrote:
> On Tue, 16 Jul 2019 07:43, firstname.lastname@example.org said:
>> describes, changed the default keyserver from the SKS round-robin pool, to a
>> *proprietary centralized service* , “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.
And I did not. ;-) I called keys.openpgp.org a proprietary *service*, not a
proprietary server [software]. I. e. a service, that has an owner =
proprietor, who solely controls it.
If you do not like the word ‘proprietary’ in its original meaning , let’s
call it simply ‘private’ (though I prefer the former since ‘private’ may also
stand for ‘personal’ = run by me for myself).
> This keyserver is not more proprietary than any other key servers.
Yes, but it’s a part (as of now, the only part) of a proprietary network — just
like, say, Facebook. While SKS is a distributed network — like Usenet.
> 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).
Yes, I positively agree with you. What software some service runs on their
machines hardly makes any difference for its user.
> A problem is the single-point-of-validation (done via mail confirmation)
> which puts them in a position like X.509 CAs.
That is, mister Brunschwig is willing to add other keyservers on a par with
keys.openpgp.org? Who will be an auditor (like webtrust.org)?
> However, in this case more like CAcert.
Like CAcert installed as the _only_ CA on a system as of now. Enigmail does
not perform searches on SKS anymore.
And Enigmail is like a software that encourages any user to get a CAcert
certificate ‘in two clicks’, not even informing him, that they are not
universally accepted. To repeat, Enigmail does neither upload keys to SKS
anymore by default, _nor ask a user where to upload_ them. Unless he is
competent enough to edit the settings beforehand, they are silently sent to
keys.openpgp.org; and keys.openpgp.org is unwilling to share the data collected
from unsuspecting users with anyone else.
> BTW, although the SKS keyserver network is distributed, its DNS is under the
> control of a single person too.
Unless you mean an entity that controls root DNS of the Internet, for sure, DNS
of SKS *network* is _not_ under control of a single person. And that’s the key
difference! GnuPG is configured by default to use some _entry point_ to a
distributed network, while Enigmail is now configured to use a proprietary
With SKS, when the default entry point is down, I can simply choose the other
one, and if I am paranoid I can command GPG to check several keyservers —
results must be identical, am I right?
> Thus the default keyserver in GnuPG has a similar SPoF but in this case the
> guy running this has quite some long term credibility.
And even if it has none. How a credibility of the owner of round-robin DNS
that randomly chooses a node in distributed network pool can be compared to a
credibility required from a single owner of the whole network?
> If Patrick (Enigmail author) wants to use keys.openpgp.org as default he can
> of course do that.
It’s hard to argue. Even if he wanted to switch from OpenPGP to some other
protocol, he could of course do that too.
He’s in fact in a halfway of doing that. Enigmail 2.1 (for Thunderbird 68, now
in beta) primarily advertising itself not as a GPG-frontend or an
OpenPGP-compatible tool, but as a PEP  software. And for PEP OpenPGP is
_not_ the preferred backend protocol, it prefer to use OTR, if possible. 
| — How does p≡p select the most secure way of sending an email or a message?
| When a p≡p user is communicating with another p≡p user:
| 1. if online communication available: OTR through GNUnet.
| 2. if online communication not available:
| a. if anonymizing platform available, OpenPGP through anonymizing platform
| b. if anonymizing platform not available, fallback to OpenPGP.
| When a p≡p user is communicating with a non-p≡p user then depending on the
capabilities of the non-p≡p user:
| 1. if anonymizing and forward secrecy is possible, use that (i.e. OTR over
| 2. if anonymizing but no forward secrecy is possible, use that (i.e. OpenPGP
| 3. if forward secrecy is possible, use that (i.e. OTR).
| 4. if hard cryptography but no forward secrecy is possible, use that (i.e.
| 5. if only weak cryptography is possible, use that (i.e. S/MIME with
| 6. send unencrypted.
It’s not possible with Enigmail yet, but the PEP-targeted interface and mode of
operation are already default for all new installations. And to get back to
the classic one, that has various features, apparently believed to be useless
now (cryptographic signatures, Autocrypt, etc), you have to go through the
following path: <main menu> / “Enigmail/p≡p” / Preferences / Compatibility /
“Enigmail Junior Mode”... And now try to guess, what option you have to choose:
( ) Automatically decide if Junior Mode should be used
( ) Force using S/MIME and Enigmail
( ) Force using p≡p (Pretty Easy Privacy)
Yes, by elimination, the second one, despite that it does not even mention
neither GPG nor OpenPGP!
Back to our topic now: what’s about keyserver? Suppose, you did not get rid of
PEP (cannot find out how, or even do not want), how do you switch an outcoming
keyserver? My answer is: no idea! I did not find any way: the ‘Expert
Settings and Menus’ (that where you had to go to before) are just missing in
PEP mode. Keys are uploaded to keys.openpgp.org and _only_ there.
Now you apparently would like to try the innovative PEP-enhanced Enigmail 2.1
by yourself to see all these fancy things with your own eyes, so I must warn
you: *it mangles ~/.gnupg/gpg.conf and ~/.gnupg/gpg-agent.conf*, so take
> 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).
May I finally propose a small thought experiment: what would you do under the
circumstances: disabled lookup on SKS servers until the installed GPG had been
updated, or took the situation as a ideal opportunity to aggressively promote a
competing private service among all you users? Or something else?
Description: PGP signature