LWN: Comments on "An update on GnuPG"

Web Key Directory and service design

ber — Tue, 07 Nov 2017 08:21:07 +0000

Some comments have been about the security implications of using the existing business relationship to the email service provider. If you want to read more about it:

https://wiki.gnupg.org/WKD points to details about how WKD/WKS is designed and what this means for users, email providers and mail users agent developers.

https://wiki.gnupg.org/EasyGpg2016/AutomatedEncryption is a draft documents with ideas how encryption can be enabled by default in many situations.

(Note: I'm one of the authors and maintainers of these documents.)

An update on GnuPG

eduard.munteanu — Thu, 19 Oct 2017 06:13:27 +0000

TOFU for SSH is a bad idea. It frequently boils down to admin laziness. You can always get the public keys on a USB stick for manual installs, it only takes a few moments. I've automated quite a few system installations and I always take care to get the PKI properly deployed, even when doing it on internal networks.

The chain of trust may need to be bootstrapped via less secure means, but there are better ways than giving up security completely (which is what TOFU does). I'd much rather get the keys via HTTPS, even from third parties. Cloning a Github repo over HTTPS is much more acceptable than using plain HTTP, even if you don't trust SSL/TLS that much.

I've found it that, In practice, it boils down to ignorance or laziness. Many open source projects fail to deliver keys and software securelly because whoever designed the distribution system does not understand or downplays crypto. The cost of a proper setup is minimal, you can even get SSL/TLS certificates for free these days, yet it's simply not implemented. And it makes the difference between trusting a pool of core people and trusting everybody along your Internet connection. A proper setup increases the difficulty of attacks enormously in exchange for a tiny cost, so there's no good excuse.

An update on GnuPG

debacle — Sun, 15 Oct 2017 21:27:29 +0000

Yes, for the typical use case removing user ids after publishing the key is probably a bad idea.

An update on GnuPG

dd9jn — Fri, 13 Oct 2017 12:37:34 +0000

Because you can't delete a user id after a key with a new user id has been published. It is called "public" for a reason;-)

An update on GnuPG

debacle — Thu, 12 Oct 2017 21:59:39 +0000

Why isn't there `--quick-delete-uid', only `--quick-revoke-uid'? I need this...

An update on GnuPG

amarao — Thu, 12 Oct 2017 15:00:26 +0000

Using 'WKS' in conjunction with email is a bad idea. WKS is already noted many times in all DNS-MX RFC's, and it stands for type of resource record for domain: Well Known Service. Yet another meaning to same acronym in the same field is a really, really bad naming decision.

An update on GnuPG

zuki — Thu, 12 Oct 2017 13:34:59 +0000

> gpg --import-options show-only --import FILE
Pfff. That's supposed to be the new nice interface?

What about something that one can actually type from memory, like
> gpg --show FILE
?

An update on GnuPG

Sesse — Wed, 11 Oct 2017 10:40:19 +0000

Is there any movement towards getting CTR modes or something similar into OpenPGP? My backup is GnuPG-encrypted, and is usually bottlenecked by the fact that only a single core can be used for encryption :-/

An update on GnuPG

robert_s — Wed, 11 Oct 2017 07:52:58 +0000

> If you don't do that, then right now your only option is the public keyservers

An interesting new approach is that of keybase.io, though I personally see hope in a hybrid approach where the web of trust is just one of many factors that can help to increase trust in a key. So here's hoping keybase.io get round to finally adding (supplemental) web of trust support.

An update on GnuPG

jaymzh — Wed, 11 Oct 2017 04:39:17 +0000

I highly recommend against building yet-another-keysigning-script... it's pretty hard to get right in a way that lends to safe keysigning.

Instead, please use something established. I recommend PIUS (https://github.com/jaymzh/pius/) (disclaimer: I wrote and maintain it) or caff (https://wiki.debian.org/caff) (not written by me).

An update on GnuPG

gdt — Wed, 11 Oct 2017 03:36:48 +0000

> where trust is built up over time?

Presumably you mean "built up with use". But it's a different measure: just because I'm regularly mislead doesn't mean that I'm not mislead.

The converse situation happens regularly. If you've ever been to a keysigning you'll have lots of highly-trusted keys (you've seen their passport, driver's licence, a mutual friend of a decade vouched for them, and no one in a room of a hundred people said they were someone else), but you might never correspond with them. Why should this lack of correspondence lower their trust score?

> If there is a peer2peer network WoT verification could be automated

Doesn't really help, as there's no reason for one p2p peer to be more trusted than another. So all the peers could announce differing public keys and you'd have no notion as to which is the genuine key.

The point of using the e-mail provider is that they can be more trusted than some other server, as the email service has additional means to associate that public key with the email address (eg, the public key was uploaded using the userid+password for the mail service).

An update on GnuPG

wa — Tue, 10 Oct 2017 23:18:45 +0000

Two noob comments/questions:

1 - Can't trust be a continuous variable rather than binary, where trust is built up over time? Once this is in place it might invite mechanisms for verifying against an increase in trust over time. TOFU would then increase trust from 0 to some base value <1.

2 - If there is a peer2peer network WoT verification could be automated. This could be a network of email contacts and presumably could be automated.

Does that make sense?

An update on GnuPG

dd9jn — Tue, 10 Oct 2017 18:59:22 +0000

I should have mention that Tom's article was about my talk.
- wk@gnupg.org.

An update on GnuPG

dd9jn — Tue, 10 Oct 2017 18:55:13 +0000

The Web Key Directory is used for key discovery and not to establish trust with mail address and key. Consider this common case: You want to write to an yet unknown person/entity and thus you need a matching key. With this protocol you can easily get a key matching the mail address. That's all. Or wait, it may help to boost the use of end-to-end encryption much like simple STARTTLS did it for transport encryption.

Shall you trust this key right away? Shall you trust this mail address right away? Shall you trust this person right away? I doubt that anyone will send confidential information to an unknown mail address. Before you can send confidential information you will setup a relationship to that person and only over time you may get an idea whether it is okay to send information which are not intended for the public. TOFU can support you here.

The less common case is that you need to write to a well known address, say The Intercept, which has a public track record suitable for your needs. Here you can get the key and manually (i.e. local key signature) mark that key as valid, for example by looking for publications with the fingerprint of the key (or well, the WoT). That needs a lot of due diligence at both ends on how to do it properly without accidentally leaking information - checking the fingerprint is only a minor part.

An update on GnuPG

droundy — Tue, 10 Oct 2017 16:44:09 +0000

While I agree that the web of trust is a broken concept that cannot scale to all of society, relying on email providers to provide trusted keys seems deeply flawed if gpg is to provide secure communications. The trouble is that the email provider is the entity one is seeking protection from, if one chooses to encrypt one's communication.