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

[Barry Warsaw]

On Mar 23, 2017, at 12:06 AM, Stephen J. Turnbull wrote:

>FYI: Encrypted lists *are* occasionally requested.

Another possible use case would be attempting to prevent the wholesale
compromise of email storage.  Meaning, if you keep your email on some external
server, and that server is compromised, if those messages are encrypted, then
at least they likely will be very difficult for the attacker to decrypt since
the keys won't likely be colocated with the emails.  Sure you can probably
phish specific individuals, but it won't be "crack the server and now you have
a million secret messages".  It's the same as with encrypted person-to-person
messages (which almost no one uses because Reasons).

>You have my permission to say "I told you so" if we're forced to
>abandon this as a silly idea.  Until then, I think you're wasting
>bandwidth in opposing it from the get-go.  Once again, I'd be happy to
>hear where our threat models are deficient once we start to talk about
>them.  But none of the proposals so far have really identified a
>threat model let alone a corresponding use case!  So there's nothing
>to criticize yet.

I should state for the record that my personal interest in this feature isn't
so much encrypted mailing lists per se, but the architectural and design
pressure it will put on Mailman 3, and our responses to that.  Encrypted lists
are the kinds of things I want to make possible with Mailman 3, so the APIs,
hooks, configurations, and plugins that would be needed to implement encrypted
lists (assuming, IMHO correctly that they won't be integrated into the core)
will be of use to others who want to do Interesting Things with mailing lists.

Cheers,
-Barry