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. -- Dean Willis _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf