If upsetting the hosts was a consideration then we should cancel Beijing. But is isn't so we shouldn't. No, the real reason not to build anti-censorship schemes into the standards is that it is doomed to failure. From a technical point of view, there are three types of censorship. The first is the type the Internet is highly resistant to. It is not possible for any one country to dominate the Internet and control what is visible in the territory of another. The second is control of the borders of a territory. The third, control within a territory. The second two are something the Internet can't address as a structural issue. We can deploy a censorship-proof Internet in the parts where governments share our objectives. We do not dominate the Internet, we cannot force governments with counter objectives to allow deployment of the censorship-proofing technology. Counter-censorship within a territory where the censor controls the infrastructure requires tactical measures. The problem with tactics is that they only work so long as they are a surprise. With all due respect to MtFBwU, I would hope that he would want us to avoid giving away information to the opposition. On Mon, Mar 22, 2010 at 2:24 AM, Greg Daley <gdaley@xxxxxxxxxxxxxxxxxxxx> wrote: > Dear MtFBwU, > > Please excuse my weasel words. > > My country is apparently about to adopt an internet censorship scheme. > I'm not happy about it, but I'm unlikely to build a system to circumvent the > "protection". > > I would actually not encourage IETF to work on such a technology as this, > particularly in the lead-up to IETF Beijing. That would be a serious affront > to our hosts. It is quite important to ensure that the IETF particularly is not > subject to any external party's agenda in the lead-up to the meeting. > > In purely technical terms, there is a conflict with IETF's existing > routing practices which are shortest (routing) path oriented, so that > communications between pairs of devices will send most or all channels > of data down the same path. > > Any form of communications which sends multiple elements down the same routing > path is subject to collation and correlation by an intermediate agency, assuming > that they use the same correlation mechanisms as the end-nodes. > > So that means using diverse data paths, or creating some sort of protected > payload is required to ensure that only the parties to a conversation can > receive the data. > > If there is a portion of the data which can be exchanged out-of-band, then a > protection scheme can be negotiated there, or the sensitive content can be sent with > the remnant providing only innocuous context. > > Alternatively, a system which can send data out-of-band which the parties > can use to shuffle the data so that sensitivity is reduced. > > In some environments use of such shuffle techniques and out-of-band channels is > not legal, and I wouldn't encourage anyone to act illegally. > > Out-of-band communications schemes such as have been mentioned are likely to be > focussed on by authorities. Participation in particular schemes could get someone in > trouble. > > Systems which increase the apparent entropy of a communication path could even be detected, > and local endpoints (for example within a protected zone) could be identified based > on the increased entropy. > > This would be dangerous for the participants, especially if they thought that > the channel they had was unidentifiable. > > IETF's job is to make Standards, which are reliable, stable and widely available. > Regardless of the focus of a protocol (routing, privacy or reliability), it's not > sufficient to create a system which is good-enough for today, but could be > dangerously ineffective tomorrow. > > I believe this is something which is not something IETF should rush into willy nilly, > ideology of participants aside. > > Sincerely, > > Greg Daley > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf