[Mailman-Developers] Encrypted lists predictable difficulties and implementation needs

[Stephen J. Turnbull]

Rich Kulawiec writes:

 > What all of this means is that once a list passes N members, where
 > we can debate about N, the probability that at least one of those
 > members has already been compromised even before they've joined the
 > list starts rapidly increasing.

This is true, but you've omitted (well, hidden in the gloss about
"correct usage") the most important source of compromise: the
subscribers themselves.

The most important use case I have in mind is not actually encrypted
lists per se, but rather anonymized and encrypted lists.  If done
properly (I have not even attempted the analysis yet, and may not be
competent to conduct it), it may be useful against garden-variety
stalkers, requiring them to access server logs or the particular
user's client (in which case they're presumably already done for) to
de-anonymize.

Of course, in most cases a competent (I'm not even going so far as
"advanced") and persistent attacker will be able to compromise a
server as well (thus "garden-variety" = script kiddie).

If nothing else, I hope to educate a half-dozen GSoC applicants that
"encryption is at best a 10% solution, and more likely 7%". :-/

And then Rich Kulawiec writes:

 > In particular, note that entities like Whisper and Signal have been, as
 > I've said for years, peddling snake-oil.  They cannot possibly deliver
 > on their promises *even if they do everything they say they can do*
 > because all of it is immediately and completely undercut if the
 > underlying system is compromised.

Compromise of the underlying systems still typically requires
cooperation from the user.  Agreed, most people who casually think,
"oh, an encrypted list! that's useful", are already busted.  "Caveat:
that word ('encrypted') doesn't mean what you think it means" should
be warning enough (for our CYA, anyway).

 > This is about building a system that is known 0% secure from the
 > start.

Is that 0% Kelvin or 0% Celsius? ;-)

 > I think, in the end, this will serve the community poorly -- because
 > people who don't grasp the contemporary security landscape will deploy it,
 > will rely on it, and will not understand that they lost the game
 > before they even started to play it.  This will have consequences.

People are already affronted that pretty much anybody who wants to can
read their email, but that's the fact and it has consequences.  I'm
not sure we need to take responsibility for that.  I'm willing to hear
more about that, but not on the basis of strawmen like "0% secure".

As Zeynep Tufekci has been at pains to point out since the Guardian
WhatsApp fiasco, that doesn't mean we shouldn't provide tools imposing
additional effort on the bad guys for use by those who do understand
the risks in this environment.

If you want to point out what use cases are broken from the word "go",
even if that includes my preferred applications, fine.  But I think
it's reasonable to expect that a number of user groups capable of
taking advantage do exist.

And he persists:

 > Moreover, none of this comes for free: there is opportunity cost,
 > complexity cost, maintenance cost, interoperability cost, etc.

It's nearly free, because there are a lot of GSoC wannabes out there
who think this is "way cool".  Disabusing them of that notion may be
the most important contribution of this project.

 > In my view, it's not worth incurring all these costs to implement
 > something that we already know, today, right now, is not going to
 > work in the contemporary Internet environment -- because it relies
 > on underlying assumptions about endpoint security that almost
 > certainly won't be true as soon as the deployment scale reaches
 > modest numbers.

I thought that it already wasn't true even before we thought up this
project, let alone when deployment can be expected to reach "modest
scale"?  Rich, calm down -- inconsistency is unbecoming of a security
professional. ;-)

Note my reply to Barry: it's not unreasonable to expect that the odds
turn against you as soon as you *pass three subscribers*.  So, yes, we
are going to have to document that to the users, and tell them they
are going to have to make serious effort to turn the odds in their
favor for *any* use case they may have in mind.