Re: message encryption with SMTP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Mon, Jan 3, 2022 at 8:43 AM Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote:
On Mon, Jan 03, 2022 at 01:10:53PM +0100, Vittorio Bertola wrote:

> As a webmail provider to several big ISPs, we offer an OpenPGP-based
> UI extension that allows users to encrypt/decrypt messages, managing
> keys etc. Not all of our customers want it, and in general, the
> feedback is that the end-user demand for e2e-encrypted email is very
> low. In the past years we put quite some educational effort in
> promoting STARTTLS and proper encryption configuration (e.g., disable
> insecure ciphersuites) and that seems to be the most of encryption
> that currently the mass market demands.

My take is that the biggest obstacle to adoption of E2E message
encryption is not key management but usability of the encrypted
content post delivery.  No IMAP user-agent supports search of
encrypted messages, private key rollover, validation of long
ago delivered messages whose signing keys are now expired, ...

I don't think we need to rank the issues, merely observe that no solution is viable unless it is the complete package and works exactly as well as legacy mail.

 
Nobody has ever paid enough attention to the whole lifecycle.
Just getting the message encrypted and delivered is only the
first step.

The Mesh is best described as a Private Key Infrastructure. PKI has failed to deliver for end users because Public Key Infrastructure only provided management for the PUBLIC key. The private key was ignored.

 
For usability, encrypted messages would need to be decrypted
by the MUA, tagged with the verification status, indexed for
(encrypted) search, re-encrypted under a long-term storage key
separate from the recipient extant private key, ...

The reason I am not interested in building on SMTP and PKIX is that the constraints they impose outweigh the benefits. I certainly plan to make use of the existing infrastructure of WebPKI CAs and it makes sense for them to deliver their work product in X.509v3 form but they are validating attributes, not keys.


Making search usable is particularly challenging under various attack
scenarios, but something like an encrypted AFS volume for the mailstore
(instead of IMAP) could be a first approximation, with the MUA searching
a locally cached index.  For most users attacks that monitor which
blocks are accessed during search are not a relevant threat model.

Encrypted search is a really hard problem as the 'scholars' who kept the dead sea scrolls suppressed for over 30 years discovered when someone reverse engineered the concordance.

PHB

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux