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

[Dmitry Alexandrov]

Werner Koch <wk@gnupg.org> wrote:
> 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.

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 [1], let’s 
call it simply ‘private’ (though I prefer the former since ‘private’ may also 
stand for ‘personal’ = run by me for myself).

[1] https://en.wikipedia.org/wiki/Proprietary

> 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 
centralized network.

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 [2] software.  And for PEP OpenPGP is 
_not_ the preferred backend protocol, it prefer to use OTR, if possible. [3]

[2] https://pep.software
[3] <https://www.pep.security/en/faq>:
| — 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 
(i.e. Qabel),
| 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 
GNUnet).
| 2. if anonymizing but no forward secrecy is possible, use that (i.e. OpenPGP 
over Qabel).
| 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. 
OpenPGP)
| 5. if only weak cryptography is possible, use that (i.e. S/MIME with 
commercial CAs)
| 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 
precautions.

> 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?

signature.asc
Description: PGP signature