Am 06.03.2011 um 16:52 schrieb Marc Petit-Huguenin:
-----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.
exellent suggestions marc, i just downloaded " offload "
I would suggest any interested person to join
http://lists.zooko.com/pipermail/p2p-hackers/2011-February/thread.html
and http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss
because there was a very interested discussion about this topic lately
regards
and nice
weekend
Marc
- --
Marc Petit-Huguenin
Personal email: marc@xxxxxxxxxxxxxxxxxx
Professional email: petithug@xxxxxxx
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
--
Les enfants teribbles - research / deployment
Marc Manthey- Vogelsangerstrasse 97
50823 Köln - Germany
Tel.:0049-221-29891489
Mobil:0049-1577-3329231
blog: http://let.de
project : http://opencu.org
twitter: http://twitter.com/macbroadcast/
facebook : http://opencu.tk
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf