Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscu

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/04/2011 08:06 PM, Dean Willis wrote:
> I just came across what may be old news to many of you. The July 2007 issue 
> of IEEE Spectrum included an article entitled "The Athens Affair", subtitled 
> "How Some Extremely Smart Hackers Pulled Off The Most Audacious Cell-Network 
> Break-in Ever". In short, perpetrators appear to have accessed the 
> lawful-intercept component of mobile switches in-use, and were able to tap a 
> lot of phones, including that of the Prime Minister of the host nation.  
> Apparently this was made easier by the fact that the user-interface for the 
> LI component had not yet been installed, making it possible for the 
> interceptions to go undetected for some time.
>
> This is just an example of a maxim: if we build nefarious mechanisms into 
> systems, SOMEBODY is going to abuse them. Otherwise said: If you build in a 
> back-door, don't be surprised when somebody sticks something in it. Sure, any 
> meathead can slap a microphone on a window, order the withdrawal of a bunch 
> of BGP routes, or cut the power to a switching center. There's not a lot we 
> can do about that. But we can do a lot about a wide variety of "man in the 
> middle" attacks, if we're willing to step up and confront the bullies out 
> there, along with the misguided who don't understand why security back-doors 
> are a two-edged sword, as dangerous to themselves as to their opposition. 
> Sure, everybody wants their systems to be "secure" and their opposition's 
> systems less so, but in the real world, everybody is somebody's opposition. 
> The only way to be safe is to have universal protections. Start by locking 
> yourself out. If that works, then it MAY stop the bad guys too.
>
> So what can we do about it?
>
> Every document we now produce has a "Security Considerations". I hereby 
> propose the following extensions to that  section, such that each 
> specification requiring a meaningful Security Considerations section MUST 
> address the following:
>
> 1)  Privacy and Integrity: We believe that intermediaries should be neither 
> able to understand nor alter the transmitted material without the explicit 
> consent and awareness of the users. How are the principles of end-to-end 
> privacy and integrity provided by the specification? Reasonable solutions 
> might include any of our well-documented encryption and signature systems 
> coupled with applicable key management mechanisms. Analysis within the 
> specification should also describe the known limitations of the 
> specification, such as susceptibility to hostile certificate authorities. 
> Further, forthcoming IETF specifications MUST not allow plain-text 
> transmission of anything within any protocol. Sign or cipher (or both, as 
> appropriate) everything, all the time.
>
> 2) Privacy and Obscurity: We believe that observation of a traffic flow pr 
> sequence of traffic flows should reveal as little information about the 
> application or user of the application as possible to an intermediary who 
> observes the traffic without the explicit consent and awareness of the user.  
> In principle, "deep packet inspection" should be completely useless, as 
> should attempts by an intermediary to trace the end-user(s) to a specific 
> physical location. How does the specification provide for obscuring the 
> content of the application and the identity and location of users involved in 
> the sequence?  Reasonable solutions might include things like TOR combined 
> with TLS. Analysis within the specification should also describe known 
> limitations of the specification, such as frequency and time domain analysis 
> at a network-adjacent node, or dependency on interceptible dereferencing 
> mechanisms like the DNS. 
>
>
> Currently we have millions of people using our protocols to defend themselves 
> from aggressors, who typically have more reach "into the infrastructure" than 
> the end users do. I know the utilization on my TOR exit relay has been 100% 
> for several months now, so there are clearly people who understand enough of 
> the problem to be attempting  some sort of defense. And we have persons in 
> authority who find open communication threatening and frequently "shutting 
> down" access to parts of the net, such as LinkedIn, Facebook, Skype, 
> Blackberry Messenger, or whatever they deem threatening on any given day. We 
> can't keep them from turning off the whole Internet, but if we design 
> protocols correctly, we can force them to choose between participating in the 
> civilization of the Internet, ALL OF IT, or being completely isolated. 
>
> If we do NOT act on this proposal, then our misguided leaders, censors, 
> tyrants, and fools will continue to be able to piecemeal select which parts 
> of the Internet they will allow, thereby manufacturing their own self-serving 
> subsets of "the truth". At the same time, criminals will continue to exploit  
> protocol weaknesses to spam, spoof, steal, and subvert. And the Internet will 
> not be the mechanism for peaceful economic expansion, prosperity, and 
> interpersonal communication that it could be.
>
>
> Much, I think, can be judged about respondents to this manifesto by the 
> nature of their response. Many will quite reasonably say "This is hard to 
> do". I agree; we can't expect immediate perfect answers, just as we know 
> we've never been able to get perfect answers to most any security question, 
> we know we will never produce perfect solutions for these issues. Others will 
> say that these goals are undesirable. I suspect that these individuals are 
> either proprietors of deep-packet-inspection tools, thieves, or accessories 
> to the overbearing governments who employ and enable the afore-mentioned 
> classes of miscreant. Others may agree wholeheartedly, but flinch at the 
> political repercussions. To them, I say: Step up. No good deed goes 
> unpunished, but at least the goal is worthwhile.  And it's probably safer 
> than standing in front of a tank or a camel-cavalry charge, although less 
> likely to get you remembered. Yet others may ask why this proposal is made 
> now, rather than the first 
of
>   next month. To them, I say that timing is everything.
There is two other interesting efforts in this direction.  The first one is
Douglas Rushkoff call to fork the Internet:

http://www.shareable.net/blog/the-next-net

Another, more concrete, one is Eben Moglen's Freedom Box Foundation:

http://www.freedomboxfoundation.org/

I any case, may I suggest a Bar BOF in Prague?  Plotting revolutions in
coffeehouses is a very old tradition.


- -- 
Marc Petit-Huguenin
Personal email: marc(_at_)petit-huguenin(_dot_)org
Professional email: petithug(_at_)acm(_dot_)org
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk1zrcwACgkQ9RoMZyVa61fpVwCfdWEon6KCA7y9rqIhnWoQ4GhB
YpEAoKkHHcTH3GKduSOKl3W2hK7FJdRF
=o/mR
-----END PGP SIGNATURE-----
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf