A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers

[Mark H. Wood]

On Tue, May 29, 2018 at 08:22:33AM -1100, Mirimir wrote:
> On 05/28/2018 12:15 AM, Werner Koch wrote:
> > On Thu, 24 May 2018 00:05, gnupg-users at spodhuis.org said:
> > 
> >> up at <https://github.com/autocrypt/memoryhole>.
> > 
> > Given that I see more and more mails with "Encrypted mail" as subject,
> > this feature is getting more and more annoying.  It will eventually not
> > anymore possible to pre-sort mails as it is commonly done either mental
> > of by tools.  Well, some MUAs might be able to auto-decrypt whole
> > folders but that opens a more severe security problem (e.g. Tempest
> > oracle) than having a plaintext subject.
> 
> That is problematic for me, because I choose to store messages
> encrypted. My correspondents and I do use generic subject, but it's not
> uncommon to have long, branching threads. So it's very difficult to find
> old stuff. No search, without mass decryption. Maybe Enigmail needs a
> search extension ;)

I think that this points out something:  while integrity and
authenticity may be bolted on using third-party packages, secrecy must
be organic to an email agent.  If there is to be a "Real-Subject:"
header within the encrypted payload, then user agents must look for it
and handle it appropriately.  This probably includes extracting and
indexing suitable encrypted labels upon decryption.  But that then
means that the index records must be encrypted.

As is often the case with devising secure facilities, much of the
difficulty lies not in how to do things but in knowing where to look
for things to be done.  Each subset of the consumers of security
practice (email is only one) needs a few trusted sources of up-to-date
best practice which focus on the ways in which that subset may be
usefully attacked.  To do good, not only must such sources exist; they
must be widely known and valued, so that people who build software
will consult them regularly when planning new projects or overhauling
existing ones.

> > We can't enforce technical security without proper OPSEC.  Regarding the
> > Subject, Reference, etc, it is way easy and more secure to educate the
> > user about the fact that only the content is _end-to-end_ encrypted and
> > other parts, like the Subject, are required to be plaintext for proper
> > routing and mail handling.

Hear, hear.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180530/2520f0ae/attachment.sig>