Please add support for configuring external keyservers like mit.edu

[whiteout-io]

Please add support for configuring external keyservers like mit.edu

[felixhammerl]

Hi,

the reason we don't support the legacy key servers (yet) is:

1. you can upload any key for any email address, keys are not authenticated, i.e. nobody cares if the address even belongs to you
2. you can't revoke keys if you're no longer in possession of the private key or forgot the passphrase, i.e. there's a ton of outdated keys out there
3. pgp.mit.edu does not enforce tls connections

that being said, we're all for making our stuff work with the legacy infrastructure, which is the reason we chose to do pgp in the first place. we haven't found the time to come up with a concept that is acceptable UX-wise and security-wise.

tl'dr:

Do we

Not yet.

Can we

Yes, probably. We just haven't gotten to it.

Cheers
Felix

[0xdevalias]

Does keybase.io suffer from the same issues as the 'legacy' providers? And if not, thoughts on implementing support?

[parvez]

Problem is that the key management is now no longer decentralized which might be security issue.
If you do open source the key management module that does the verification, it could help in decentralizing the key management. Users or organizations could host these Key Management servers that could act as an option. Keys could be synced between trusted Key Management servers. I am afraid right now we have one point of failure.

[tanx]

Thanks for your comments. I’ll answer your questions before diving deeper into key distribution.

Does keybase.io suffer from the same issues as the 'legacy' providers? And if not, thoughts on implementing support?

Keybase provides better authentication of public keys than standard key servers, but they don't solve the problem of centralization that @parvez mentioned.

If you do open source the key management module that does the verification, it could help in decentralizing the key management.

Well maybe. Keep in mind that a list of trusted key servers would still have to be maintained somewhere so the client could know which servers to query. Otherwise keys from organization A would not be available for organization B.

In terms of open sourcing our server components, we have currently only open sourced the client. Our thinking behind our open source strategy is described here:
https://blog.whiteout.io/2014/10/17/webmail-and-open-source/

I am afraid right now we have one point of failure.

Agreed. To put all these things into perspective, let me try to give an overview of the current landscape of key servers.

Some discussions for future reference

Problems with "legacy" key servers

Here's the wikipedia article about "legacy" key servers that lists the issues @felixhammerl mentioned:
http://en.wikipedia.org/wiki/Key_server_%28cryptographic%29#Problems_with_keyservers

The Google way

Google is doing some very interesting work on public key distribution that we are following closely. Here are some references from their wiki:

Key Distribution: https://github.com/google/end-to-end/wiki/Key-Distribution
Key Log Server: https://github.com/google/end-to-end/wiki/Key-Log-Server

Our current approach

All in all though, key distribution is a hard problem with no easy answers. We have chosen our simple key server solution under https://keys.whiteout.io as a first step mainly due to ease of use. Here is the current „protocol“:

1. When a user logs into Whiteout Mail with their email address for the first time, their public key gets uploaded and authenticated via email. The client does this automatically in the background. But basically we check that the user received a token sent by us via email. We then delete that message, so that users don’t notice this.
2. Whenever other users type in that email address while composing a message, the client fetches an authenticated key from our server. This will obviously only work if both users use Whiteout.
3. Users can also revoke a public key here: https://whiteout.io/revocation.html

While we know this is far from ideal, we believe it is much better than the status quo.

Advantages:

1. It's easy for average users, who don't want to understand the intricacies involved with key distribution.
2. It's more secure than „legacy“ key servers. There is a central authority (us) that authenticates keys and lets users revoke keys, while still providing a way to verify fetched keys via standard fingerprint comparison methods.

Disadvantages:

1. If you don't check key fingerprints, there is obviously more trust involved towards us, but keep in mind that this is still better than the "legacy“ key servers where anyone can upload a public key for you.
2. It’s a closed system and does not work with „legacy“ key servers and clients.

A potential future approach

We've discussed your suggestions yesterday and here is our suggestion on how we could provide support for „legacy“ key servers, while still providing the value add of our own key server.

1. When a user composes a new message and enters another user’s email address, the client first queries the local keychain. This keychain includes cached keys from our own key server as well as manually imported keys from any source.
2. If the recipient’s key is not found in the local key ring the client then queries our own key server. If a key is found, it will be used to encrypt the message. The user will also be notified in the UI with the recipient’s key fingerprint and a color that represents „key authenticated by whiteout“.
3. If there is no key for the recipient on our key server, a list of well known „legacy“ key servers like pgp.mit.edu is queried. If a key is found the user is notified and is asked if he wants to trust this key, after which it is imported to the local key ring.
4. If no key is found from any of the sources described above, we can safely assume that the recipient does not use PGP yet and an „Invite to Whiteout“ button is presented to the sender.

Note: we already have invite to Whiteout functionality. But only in the reader for incoming mails.

What do you think? Does this make sense?

[aw]

This is a really great discussion and answers the initial concerns I had regarding the whiteout key distribution implementation. Also thanks for making your stance publicly known.

I think the potential approach is good, but there is one issue:

If a key is found the user is notified and is asked if he wants to trust this key, after which it is imported to the local key ring

This option runs the risk of a user simply choosing "yes" without actually verifying the key's fingerprint.

Perhaps you can implement something similar to Telegram's secret chat, where they can compare a QR code with one that's generated/stored in a trusted location?

I haven't fleshed out the entire answer to this problem, but this might be a good direction if we remember the end-user will likely not be as technical as most GPG users.

[tanx]

This option runs the risk of a user simply choosing "yes" without actually verifying the key's fingerprint.

I've thought about this too. I'm a big fan of visualizations like the QR code when they improve the UX. Even my non-technical friends seem to understand that they should scan my QR code in Threema. Having said that, I'm not sure how the QR code will help in the case of fetching from an untrusted key server (unless the recipient has already given me a business card with the code or fingerprint, which is not a common practice among average users).

Another solution could be to let users upvote other user's keys to mark them as trustworthy. E.g. if several of my existing contacts have already upvoted the fetched PGP key for a new recipient, it would make it easier for me to decide to trust a new key.

[parvez]

Thanks for you open response. I truly appreciate what you guys have contributed to the Open Source Community. I understand the key management is one of the biggest challenge for PGP and your solution is the best currently.

It would be nice if you sync the keys from the public key servers (mark them as untrusted) and have the user select for the correct one when sending email. This way the user sending would be able to reach to users who are not using whiteout.io service as well.

Lesson learnt from Google Wave is to give users larger reach. If this is successful banks could be able to send and receive encrypted emails to their customers. I know its far fetched but thats what I envision.

[aw]

I'm wondering if it would be simpler to plug into existing systems which are likely to already have a person's verified identity, ex: twitter, facebook, google+ profiles.

Could you perhaps integrate with something like keybase.io ?

[tanx]

Keybase is cool, but the system is just as closed as our current key server. What I'm suggesting is visualizing the OpenPGP Web of Trust similar to facebook's social graph like so:

This would reuse the data that is already stored on servers like pgp.mit.edu and display it with a new frontend so that average users could understand it. Nobody understands what it means to sign a PGP key, but everyone understands what a link between two people means. Users could "upvote" other user's identities by clicking on the link. This would sign the other user's PGP key in the background and upload the signature to a standard key server.

[parvez]

That's an awesome idea. I love the fact that you strive to make PGP easy to use for the average users. I love this concept. Can we start building a Proof of Concept for this visualization? I would love to contribute and could help in that.

How would you integrate this with whiteout?

[tanx]

@parvez no timeline on the Web Of Trust graph browser yet, but HKP server integration has been added in:

https://github.com/whiteout-io/mail-html5/tree/dev/WO-862

Basically our keys.whiteout.io keyserver will fetch keys from pgp.mit.edu in case no key is available and tag the key object with a source attribute. The sync works both way, so keys are uploaded to pgp.mit.edu after the email address has been verified on our server.

The client can't query pgp.mit.edu directly since the old pks servers don't support CORS headers required for cross-origin requests. That's why our key servers acts as a proxy.

The cool thing is that the user never has to worry about manually importing keys this way as keys will be fetched automatically during read/write of messages. We thought about displaying a dialog to let users confirm a hkp key, but decided on a TOFU (trust on first use) workflow for ease of use. That way average whiteout users can write encrypted emails with technical GPG users and it will just work.

Closing this issue... the feature will be in the upcoming release.

[tanx]

v0.22.0 has been released and includes the HKP server integration (release notes).

You can install it here: https://whiteout.io/#product

We'll write a post on how this works in detail on our blog soon. Looking forward to your feedback.