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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf