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

[Trevor Perrin]

Tankred wrote:
>>
>> When people talk about using the Signal protocol for email, I think what
>> they are mostly referring to is the painless user experience for key
>> distribution. Which is why I think we should borrow UX concepts for email
>> that have proven to work at scale for Signal. Our first attempt at this for
>> Mailvelope is a very simple key server that allows reliable TOFU/auto-lookup
>> (no key transparency included). We’re planning to launch integration in the
>> Mailvelope extension in July.
>>
>> More info and links to the code here [2].
...
>> [2] https://keys.mailvelope.com


Hi Tankred,

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.

---

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?


Trevor


[1] https://moderncrypto.org/mail-archive/messaging/2016/002215.html