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

[Craig P Hicks]

Thanks Phil. Very interesting!  I will look into that.

On Wed, May 23, 2018 at 3:05 PM, Phil Pennock <gnupg-users at spodhuis.org>
wrote:

> On 2018-05-22 at 19:35 -0700, Craig P Hicks wrote:
> > "A Solution for Sending Messages Safely from EFAIL-safe Senders to
> > EFAIL-unsafe Receivers"
> >
> > https://github.com/craigphicks/efail-safe-send-to-insec-recv/wiki
>
> There's an existing semi-standard for trying to improve email security
> by moving headers inside the body and having MUAs handle that
> consistently; the main website has gone, but the spec seems to still be
> up at <https://github.com/autocrypt/memoryhole>.
>
> You might consider blending your proposal into that and talking with the
> Memory Hole folks (Daniel Kahn Gillmor wrote the spec) about whether or
> not the email headers in the header block (text/rfc822-headers section)
> might start with a new Efail: header which can be completely ignored for
> display purposes.
>
> This buys you complete independence from the type of the payload,
> inserting only into the headers; you lose the "first 14 bytes" part, but
> you were incompatible with MemoryHole anyway, and I get encrypted mail
> from a few MemoryHole users already, so there's a userbase there.  If
> it's the first header, then there's nothing sensitive earlier in the
> encrypted message.  Advocating for MUAs to default to "efail-proofed
> memoryhole format" for encrypted mail _might_ gain traction?
>
> -Phil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180523/52d8be18/attachment.html>