[Tails-dev] Memory Hole: strategy and timeline

[intrigeri]

Hi Daniel!

(I know you follow tails-dev@ somewhat but today I'm writing you with
your "Memory Hole driver" hat and I want to make sure you notice this
message, hence the explicit To header. I've set Reply-To to this list
so you should not get more duplicates.)

At a recent [Tails meeting] we've decided to tweet ([Tails ticket])
about how cool Memory Hole is, about the fact that we would like to
enable ASAP, and the fact that we are currently blocked by the lack of
Memory Hole support in the email client landscape. We hope it will
help motivate email client developers to implement Memory Hole
support. This email is not meant to discuss again whether Tails should
send Memory Hole-protected email by default right now, but instead to
gather input so we maximize the impact of our lobbying in favor of
Memory Hole :)

I would like to coordinate with you because the current Memory Hole
status makes the overall strategy/timeline around it unclear to me:

- The [draft spec] is incomplete e.g. guidance for email client
developers is lacking on important aspects such as how to handle
headers apart of Subject; I suspect the discrepancy wrt.
headers handling between Enigmail 1.9.9 and 2.0~beta1 is at least
partly caused by this lack of guidance.

- Threading, an important email feature, is broken when composing
replies using the 1.9.x releases of Enigmail, that is currently the
only implementation of Memory Hole in a widely used desktop email
client. Thankfully that's fixed in Enigmail 2.0~beta1 but we can't
expect Debian users to guess they need to install software from the
'experimental' repo in order to avoid regressions in basic email
functionality; I think the situation is even worse for users of
other operating systems, that is the vast majority of
Thunderbird users.

To maximize the impact of our tweet, I believe these two issues should
be addressed first, that is:

- The world-famous $someone should ensure we can point to
a specification that email client developers can follow to do the
right thing; and in particular, recommendations should require that
threading must not be broken.

- A working desktop example should be made widely available, that is
Enigmail 2.0 should:
- be released as stable
- be the default version non-technical users can install via
whatever installation/upgrade methods the Enigmail project
supports
- be available for Debian stable users at least via stretch-backports

So my questions are:

- Does the above make sense to you?

- Is there anything else you think should happen before we send
our tweet?

- Are you in a position to give us a (rough) schedule wrt. when the
above blockers will be resolved? In particular, do you personally
plan to work on the specification again in the near future?

Thanks in advance!


[Tails ticket] https://labs.riseup.net/code/issues/13649
[Tails meeting] https://tails.boum.org/contribute/meetings/201712/
[draft spec] https://github.com/autocrypt/memoryhole/blob/master/specs/draft-memoryhole.md


Cheers,

[intrigeri]

Post by intrigeri
Hi Daniel!

Ping?

(Initial request sent on https://mailman.boum.org/pipermail/tails-dev/2018-February/012032.html)

[Daniel Kahn Gillmor]

Hi Intrigeri and tails folks--

I'm really glad you're thinking about protected headers! sorry for the
lag in this, much of which appears to be attributable to me :/

Post by intrigeri
At a recent [Tails meeting] we've decided to tweet ([Tails ticket])
about how cool Memory Hole is, about the fact that we would like to
enable ASAP, and the fact that we are currently blocked by the lack of
Memory Hole support in the email client landscape. We hope it will
help motivate email client developers to implement Memory Hole
support. This email is not meant to discuss again whether Tails should
send Memory Hole-protected email by default right now, but instead to
gather input so we maximize the impact of our lobbying in favor of
Memory Hole :)

I think there are two baseline factors that you want to be thinking
about for deployment:

* being able to safely/sanely read/consume "memory hole" messages (or
other protected header schemes)

* being able to send protected headers (including on reply)

Once those are in place, then it's worth thinking about the harder
stuff:

* for encrypted messages, now that you have protected headers which
ones should you strip/stub from the outside?

Post by intrigeri
I would like to coordinate with you because the current Memory Hole
- The [draft spec] is incomplete e.g. guidance for email client
developers is lacking on important aspects such as how to handle
headers apart of Subject; I suspect the discrepancy wrt.
headers handling between Enigmail 1.9.9 and 2.0~beta1 is at least
partly caused by this lack of guidance.

I think the answer here is that for that draft to get completed, we need
more people looking at it, implementing it, and commenting on it. There
is some level of interest (both within autocrypt, and within the IETF)
to concretely document what's being done here.

Post by intrigeri
- Threading, an important email feature, is broken when composing
replies using the 1.9.x releases of Enigmail, that is currently the
only implementation of Memory Hole in a widely used desktop email
client. Thankfully that's fixed in Enigmail 2.0~beta1 but we can't
expect Debian users to guess they need to install software from the
'experimental' repo in order to avoid regressions in basic email
functionality; I think the situation is even worse for users of
other operating systems, that is the vast majority of
Thunderbird users.

To be clear: i think that enigmail 1.9.x does *not* stub out the subject
header by default -- it just knows how to deal with stubbed headers.

The main reason that enigmail 2.0 is still in experimental instead of
better propagation is because of the OpenPGP.js mishegas. i really need
help in sorting out the endless stream of node dependencies (and
sub-dependencies, and sub-sub-dependencies
) that seems to be par for
the course in the node ecosystem :(

See https://bugs.debian.org/896846 for more detail.

the other approach, which i'm starting to experiment with here, is to
strip openpgp.js from enigmail and to see what breaks :/

Post by intrigeri
- The world-famous $someone should ensure we can point to
a specification that email client developers can follow to do the
right thing; and in particular, recommendations should require that
threading must not be broken.

I think that the best place to encourage that work would be in the
Autocrypt project -- there are multiple developers there who have
already implemented or are implementing protected headers. I welcome
discussion there about how to get that draft turned into something
useful.

Post by intrigeri
- A working desktop example should be made widely available, that is
- be released as stable
- be the default version non-technical users can install via
whatever installation/upgrade methods the Enigmail project
supports
- be available for Debian stable users at least via stretch-backports

This sounds great. Unfortunately, the openpgp.js dependency tree is
what's blocking it. I will try to make a better documentation of the
dependency hassle there, and i welcome help with packaging any of the
piecemeal node bits that we might need.

And i will see whether i can make an OpenPGP.js-free version of enigmail
that isn't too painful.

It looks like ripping out OpenPGP.js will involve problems with:

* previews of keys that the user is considering importing

* autocrypt setup message (a mechanism that lets you transfer data
between autocrypt clients)

These seem like prices worth paying to me, so maybe this is the
best/simplest path forward, as it gets the best tools in the hands of
more debian users.

Post by intrigeri
- Are you in a position to give us a (rough) schedule wrt. when the
above blockers will be resolved? In particular, do you personally
plan to work on the specification again in the near future?

I do plan to work on the specification! But i don't have a concrete
timeline.

I have pushed an implementation for reading protected headers in
notmuch, which is still waiting for review there. I welcome review on
the notmuch mailing list.

I will also try, over the next week, to make a version of enigmail that
doesn't include openpgp.js so that we can include it in debian.

--dkg

[intrigeri]

Thanks a lot, Daniel, for this thoughtful reply!

It clarified to me what exactly we're waiting for before we can write
our tweet. I'll come back to it in a few months and reassess
the situation.

Unfortunately I'm not in a position to offer any help besides this :/

Thanks for your work on making email safer!

[intrigeri]

Hi,

Post by intrigeri
- A working desktop example should be made widely available, that is
- be released as stable
- be the default version non-technical users can install via
whatever installation/upgrade methods the Enigmail project
supports
- be available for Debian stable users at least via stretch-backports

This sounds great. Unfortunately, […]

After months of tireless (and seriously frustrating) efforts, dkg
managed to get Enigmail 2.0 into Debian stable. Congrats!

So the only blocker left for Tails to tweet about this is
the specification.

I have pushed an implementation for reading protected headers in
notmuch, which is still waiting for review there. I welcome review on
the notmuch mailing list.

Great, I'll reply off-list :)

Cheers,