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 _______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
