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

[Jan Jancar]

On 03/21/2017 11:16 PM, Rich Kulawiec wrote:
> On Tue, Mar 21, 2017 at 04:04:20PM +0100, johny wrote:
>> Shifting the attacker to actively compromise devices is an overall
>> improvement.
> 
> If "compromising devices" was difficult, I might agree.  But it's not.
> Devices of all descriptions have been and are being compromised in
> enormous numbers on an ongoing basis even by relatively unskilled
> attackers -- since they can buy/lease the requisite tools and infrastructure
> and use them without needing to understand how they work.
> 
> I think you (and others) are continuing to badly underestimate the
> scale at which this is taking place.   We're not talking about an
> ecosystem in which 2% or 6% of devices are compromised; we're talking
> about one in which any estimate under 25% should be laughed out of
> the room and an estimate of 50% should be given serious consideration.
> (I think the latter may be still be too high.  But it's certainly
> within the realm of plausibility.)   We're also talking about an
> ecosystem in which, increasingly, vendors are shipping devices that
> are essentially pre-compromised at the factory due to very poor
> and entirely self-serving design and implementation decisions.

Before introducing encryption during transport an attacker had a
choice to either sniff traffic or compromise a device. Plugging one
hole, encrypting the transport, *MUST* be an overall security
improvement, it will not be only in some edge circumstances.

I think that the percentages you are presenting are not the right
ones for what you could expect from users of a GPG encrypted mailing list.
    a) The fact that they are even considering to subscribe to an
encrypted mailing list, that they have a GPG keypair moves the
probability that they are doing this on a compromised device way lower.
(at least I think so, I don't have any concrete data)
    b) You are assuming that the percentages you give are actually all
one homogenic attacker, aimed at gaining access to an encrypted mailing
list, having the capabilities to do so and having control of X% of
devices. No such one attacker actually exists.


>> There are plenty of threat actors for which sniffing traffic to a
>> plaintext mailing list might be easy, however overcoming a well setup
>> encrypted mailing list system would be quite hard.
> 
> I don't think so, if the mailing list is of sufficient size.  (Certainly
> one with only a handful of people might be hard to crack, but that
> would be fairly hard today even without encryption.) 
> 
>> The system security only increases in this case. It's security is
>> obviously debatable against state actors/equivalent threats, there it
>> might not improve much, but improves significantly against other threats.
> 
> State actors are not necessarily the biggest threat.  They might
> have the most resources, and they might have the best cryptographers,
> and they certainly have the most political power (e.g., NSLs in the US),
> but they also have their own areas of focus and this may not be one of them.
> 
> If there's money to be made by trafficking in information, then others
> will take an interest.  They may not have the resources, cryptographers,
> power, etc., but they do have some very talented personnel, stockpiled
> exploits, and rather a lot of experience with mass compromise of end
> user systems.  These are not script kiddies in mom's basement, these
> are professionals with the discipline to identify and attack targets
> successfully on a large scale.  Don't underestimate them.  *That*
> particular mistake was already made by every ISP on this planet ~15
> years ago, which is one of the major reasons the problem has the
> scope that it has today.

I still think that there is a security improvement that outweights the
drawbacks. Of which two were noted:

   a) Mailman's encrypted mailing list security will be over-estimated
by naive users that will get bitten by this.
      This is valid for cases where the users aren't already
communicating in an insecure way (which is likely), so only covers a
small userbase and can be tried to be mitigated by proper warnings,
documentation, common sense. (As many E2E and similar apps do, or should
do, warn that endpoint security is important and that endpoint
compromise is catastrophic)

   b) Added complexity, maintenance cost to Mailman's infrastructure.
      This can be mitigated by implementing encrypted mailing lists
either as a plugin as was proposed here before, or just by making the
feature as non-intrusive into Mailman's infrastructure as possible .
(which I think is doable if the proposal aims to do so)

-Jan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20170323/fb7fffb8/attachment.sig>