No Internet Wiretaps
Pig Hogger writes "It's official. The IETF has officially decided NOT to
" consider requirements for wiretapping " in protocols, says this
Wired.com
story.
Now that they won't touch it, does this means that the vendors will implement it themselves? If so, I can't wait to see the backstabbing and fumbling that will happen when they will try to keep their proprietary ways under wraps... What will we see, a CISCO wiretapping standard, which is thoroughly incompatible with the Lucent Bugging Protocol??? "
The IETF has been asked to take a position on the inclusion into IETF standards-track documents of functionality designed to facilitate wiretapping.
This memo explains what the IETF thinks the question means, why its answer is "no", and what that answer means.
That's what I call "style".
Please moderate this post to zero points.
-- My comment is above.
The abstract makes these observations:
- Experience shows that tools designed for one purpose that are effective for another tend to be used for that other purpose too, no matter what its designers intended.
- Experience shows that if a vulnerability exists in a security system, it is likely that someone will take advantage of it sooner or later.
If only other protocol designers (e.g the DVD-CCA) would keep such things in mind when designing their products, instead of trying to legislate/litigate unintended uses and security breaches away after the fact, we might avoid a great deal of trouble. Weak security will usually be broken sooner or later. And for goodness' sake, don't sue your customers when they use your products in ways you didn't intend.
Quantum mechanics: the dreams that stuff is made of.
As a (silent) member of the raven list for some time, I find the draft interesting for the difference between the draft itself and the raven discussion. The decision to take this position was likely a foregone conclusion on the part of the IAB members. I'm not criticizing it -- it was still the only honest position that IETF could have taken. But the IAB members didn't get much from the raven list. Reading the raven list made it clear that technically minded people sorely need to learn when to concentrate on "how", and when to concentrate on "why".
What the open source community should take from this is twofold:
First, concentrate on the "why" of building successful long-term technical solutions. Resist all attempts by commercially interested parties to water down a design to satisfy other-than-technical considerations. The raven list was littered with posters (generally from equipment manufacturers) pleading "but we haaaaave to do this eventually anyway".
The fact that purchasers of Cisco or Lucent carrier-class equipment might want, or need (for legal reasons), central office wiretap capability to satisfy future government dictates is, quite simply, their problem and not IETF's.
The open source community should be similarly resistant to appeals to water down the GPL or litter the kernel with vendor-initiated hacks out of convenience.
Second, concentrate more on the "how" of presenting open source viewpoints and solutions to the non-technical community. The IETF's draft is a model of how to do it right. The raven list was not. In venerable Usenet style, the posters loudly advanced moral answers to technical questions and technical answers to moral questions. Nazi Germany was invoked multiple times.
What the IETF's draft does so well is to separate the two and answer each in its own way, concentrating each time on the things that IETF actually has the capability to do something about. This attribute is what elevates the IETF's draft from a rant to a considered policy statement.