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

On Mar 11, 2011, at 7:13 PM, Mark Nottingham wrote:

> > You mean some third-world (or soon to be) junta-dictator might officially 
> > and deliberately cut their economy off from the world's communication 
> > networks, thereby insuring economic failure, rather than suffer the risk 
> > that their citizens might be exposed to external influence or use the 
> > Internet to complain about or conspire against their "lawful leaders", 
> > rather as North Korea has done?
> >
> > I'm OK with that. It helps bring about their failure due to economic 
> > collapse rather than requiring outside force to stop their depredations, 
> > although it might take a few generations to work.
> ... compared to the much faster social changes that have been witnessed in 
> places where there's been even partial exposure to external information, that 
> seems like a poor outcome. Collapse is messy and very dangerous for the 
> people you want to help.
How likely are people in even the most restrictive regime to not have even 
partial exposure to outside information, no matter whether IETF protocol 
specifications have richer security considerations than we currently practice?


> > I'm also okay with air-dropping satellite terminals and television receivers 
> > to their victims, and with beaming high-power wireless signals across their 
> > borders in order to speed things up.
> And how likely are those things to actually happen and have a measurable 
> effect? Seriously. 
Ever heard of the Voice of America program? Most developed nations have 
something similar. Did you see all the satellite dishes on the walls of houses 
in Cairo?

Now, this does raise an entirely different question more related to parallel 
efforts to make self-organizing ad-hoc networks useful. This is a really good 
effort, useful in everything from economic growth efforts like OLPC to 
recovering from a Japan-earthquake-style major disaster. We should probably be 
working on this sort of thing harder than we presently are.


> I have severe doubts about whether this is an appropriate and capable forum 
> for making such weighty judgements. YMMV.
Well, we certainly shouldn't be  trying to decide which nations thrive and 
which collapse. But we ARE responsible for the security characteristics of our 
own protocols. We're quite willing to talk about security, and make protocol 
specifiers jump through intricate and mostly useless hoops in their spec 
writing, but we don't seem to be willing to put our "money where our mouth is."

For example, why are we still running our web sites on HTTP instead of HTTPS? 
If we only had the latter, it becomes much more difficult for MITMs to know 
whether a person communicating with the IETF web site is participating in the 
IETF process or just using us as a web proxy to talk to Facebook about The 
Revolution. If all traffic is encrypted, and if the apparent endpoint might or 
might not be a relay instead of the actual endpoint, then it's a whole lot 
harder for the MITM to separate wheat from chaff. Many of our protocols support 
this sort of obscuring, but our practice has been to disable the functionality 
through implementation choices.

On a related note, we've developed what we think is a secured mail protocol 
suite. Yet we don't use it, instead subjecting our list members (and more so 
the administrators) to having to deal with an endless barrage of spam. We 
probably don't use our secured mail protocol because it is too cumbersome. 
Maybe that should be a wake-up call for us to develop a better way to secure 
mail.

But instead of doing practical things that actually impact security, we 
endlessly debate things like the distribution-reuse flags for geolocation 
objects (which will be generally ignored by implementors) and write 
specifications like the Consent Framework for SIP that will most likely never 
be implemented.

Most critically, we've recognized that Internet users may have needs for 
privacy (which until recently has meant just encryption of data) and integrity 
(minimally, signing of data). It's time we recognize another fundamental 
principle: obscurity (hidden purpose of data). And having recognized these 
principles, we need to start taking much more aggressive steps in protocol 
design to assure that they are actually being met in a useful way.

We can start by:

1) deprecating the non-secured variant of every core protocol that has both 
secure and non-secure variants 

2) not writing any more protocols with secured and non-secured variants

3) analyzing existing protocols that are fundamentally non-secured and 
determine which, if any, security enhancements should be made normative 

4) Doing a much better job of really analyzing the security considerations of 
new work, taking fully into account the principles of privacy, integrity, and 
obscurity. Keep in mind that every protocol has the "good citizenship" 
responsibility not just of addressing these principles itself, but of also 
helping its fellow citizens meet them.

5) Incorporating the principles of Privacy, Integrity, and Obscurity directly 
into our core mission statement, into the very fabric of our belief system, 
just as "Liberté, égalité, fraternité" became the driving motto of the Third 
Republic of France, ending much of the abuse of Privilege that preceded the 
revolution.

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