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

I am rather skeptical.

At this point the secret is out and the potential of the Internet and the
Web is rather too well understood.

Documenting the privacy issues raised may well serve more to provide
dictators with ideas than actionable advice and even if the recommendations
are actionable there is no guarantee they will be acted on.


We really need to progress from looking at the effects we wish to achieve
and design technology that is designed to meet those ends.


On Sun, Mar 6, 2011 at 10:52 AM, Marc Petit-Huguenin 
<petithug(_at_)acm(_dot_)org>wrote:

> -----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


-- 
Website: http://hallambaker.com/

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf