On Thu, Mar 16, 2017 at 12:47 PM, Rich Kulawiec <rsk@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.