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

[Morgan Reed]

On Thu, Mar 16, 2017 at 12:47 PM, Rich Kulawiec <rsk at gsp.org> wrote:

> I think that this is an instance where a huge amount of well-intended
> design and development effort will result in a "solution" that cannot
> provide what it intends to because underlying circumstances prevent it.
> And -- having studied those underlying circumstances for a long time --
> I can sadly report that the problem is getting worse and will continue
> to get worse, because (a) all of the various factors contributing to it
> are also getting worse and (b) there are no reasons for anyone to
> significantly invest in making it better.
>

I'd submit that this is tantamount to saying "it's impossible to make a
100% secure system so why bother even trying".

Yes, a straight forward encrypted remailer such as is being discussed here
has limited applicability, and will require careful implementation to
function "properly" in the "real world". However I'm certainly aware of
several organisations who would happily use such a platform, in a limited
capacity for endpoints which have already been hardened. Nobody expects
that when this work is completed that every mailman list in the world will
suddenly become encrypted, because it won't and the VAST majority of them
never will.

Anything that raises the barrier to entry for surveillance is a good thing
IMO, if you go from being able to "passively sniffing plaintext off the
wire" to having to "actively compromising an endpoint" that is still an
improvement in your security posture and that is the way things change,
incrementally.

Somebody else on the thread has raised the point of whether this should
actually be implemented in core or if we should merely expose API to enable
this functionality to be added plugin-wise, I think that's a debate that's
worth having, but suggesting we write the whole thing off because "all
these nodes are already compromised" is not remotely useful.