[messaging] Mailvelope Key Server and "fallback" keyservers (was Re: Axolotl for email)

[Tankred Hase]

Hey Trevor,

thanks for your input. Comments inline...

> Am 27.06.2016 um 21:22 schrieb Trevor Perrin <trevp at trevp.net>:
> 
> Nice experiment!
> 
> I'm curious how this compares to the "encryption profile" idea, which
> was to integrate some generic keyserver functions into email servers
> [1].
> 
> Integrating keyserver and message handling has some benefits:
> 
> (1) Automatic registration of public keys through the recipient's
> POP/IMAP server, so there's no need for a manual process (responding
> to an authentication email).
> 
> (2) Senders fetch recipient public keys from the same SMTP servers
> they deliver messages to, so there's less risk that a corrupted or
> MITM'd server could provide unreliable public keys, causing
> undecryptable messages.
> 
> (3) SMTP servers would reject messages encrypted to outdated public
> keys (otherwise, senders would need to perform a public-key lookup
> prior to sending every encrypted message, to ensure they don't send
> undecryptable messages to old keys; these extra lookups are less
> efficient).
> 
> There's also benefit to having generic keyserver functionality,
> instead of tying this to PGP, so that clients can publish different
> things (prekeys, certificates, WoT or transparency data, links to
> other keyservers, etc), and the system has some ability to evolve.

That is all correct. In a perfect world, mail providers would agree on a common standard and deploy something in a finite amount of time. Correct me if I'm wrong, but I'm not seeing a lot of action from the big/relevant mail providers. Which kind of leaves PGP plugins to find a solution.

> ---
> 
> You're planning for "fallback" keyservers, "in case a mail provider
> does not provide its own key directory".  I understand the appeal -
> without fallback keyservers, we're dependent on mail providers to
> deploy stuff.  But fallback keyservers don't have the advantages of
> mailserver integration, so I'm wondering how viable they really are.
> 
> (2) seems like the hardest issue.  A keyserver can provide wrong /
> outdated public keys to disrupt communications (by causing
> undecryptable messages).  An integrated keyserver is part of the
> recipient mailserver, so it's already trusted for reliable delivery.
> But a fallback server means trusting a new entity (or set of
> entities).
> 
> How would that trust be distributed?  Would there be a single fallback
> keyserver, used by everyone?  Or a network of such keyservers that
> trust each other (any one of whom could disrupt anyone's mail flow?)
> Or something else?

The current proposal lacks a robust concept for trust agility and federation. This is true. Our vision is a federated concept [1]. Granted, there is no fleshed out concept for this yet though.

We burned through alot of resources at whiteout.io building a lot of fancy tech. My takeaway from that mistake is to take baby steps and validate with reals users early. The current proposal is to start from the user experience and work backwards towards the technology/crypto. That's probably not a very popular position on this mailing list. But if this experiment does not prove successful, there is no point in investing the time and energy to specify the perfect federated architecture.

It probably won't move the needle much in terms of PGP adoption though. At least not until the big providers build end-to-end into their services/apps. As Bruce Schneier says: "one click is one too many". Which is why I would recommend anyone use Signal if they can avoid email and are comfortable with giving out their phone number.

Tankred

[1] https://github.com/mailvelope/keyserver/blob/master/README.md#standardization-and-decentralization