15 July 1998
To: firstname.lastname@example.org Subject: Ding dong! Facts calling! (Private Doorbell) Date: Wed, 15 Jul 1998 17:49:16 -0600 From: John Bashinski <email@example.com> I thought you might all like a small injection of reality vis-a-vis Private Doorbell. First, a few key facts about the proposal... 1. The are no back doors. Neither Cisco, nor any government agency, nor anybody else other than the administrator of a router, is to be able to do anything without asking the administrator. The administrator, just to avoid confusion, is the owner of the router, or whoever the owner has appointed to manage it. In other words, if the FBI wants some packets, they have to call up the person running the router, at either the encrypting end or the decrypting end, and ask. They must ask the person; they can't ask the router itself. They will presumably have to show a court order when they ask. There is no provision for surreptitious surveillance. Back-doored products are not salable. Our customers have been most emphatic in making this clear to us. 2. There is no special traffic diversion capability. Obviously, the administrator can, and always has been able to, exercise some control over where a router sends packets, and obviously, the administrator can reconfigure the router remotely. However, there is no provision for anything to be done outside of the normal functioning of the router. 3. There is no provision for "copy and divert" (that's almost undoable in our architecture, anyway). Most of the time, you have to either attach monitoring equipment directly to the router, or reconfigure the router not to encrypt the traffic in the first place. 4. There is no weakening of encryption, nor any "watering down" of security standards, nor any complicated management or recovery schemes to have security bugs. 5. In fact, the proposal involves no changes *whatsoever* to our existing, shipping software. That's right, folks, the code does not change. Under our proposal, the only change will be that we'll be allowed to use longer key lengths. The whole Doorbell thing is implemented by the administrator using existing configuration options, and not particularly arcane options, either. I very much doubt that any code change would be required in any router from any vendor. There's no change in the technology. The change is in the way you see things. In the real world, when a router is doing encryption, the person whose traffic is being encrypted is usually not the person who runs the router. A router does generally encrypts traffic for a whole network of end-user machines. Although ISPs do offer encryption services, a more common case is for a business to encrypt all the traffic passing between its offices. Usually, a company trusts its LANs, but does not trust its remote links. If an employee of such a business is doing something that law enforcement is interested in, then law enforcement can go to the employer and get the traffic without alerting the employee. The exact same thing happens when law enforcement wants to do a traditional wiretap against somebody whose phone is on a PBX. In those situations, they go to the PBX operator, and get the tap done there. They do this routinely, they're set up to deal with it, and it generally seems to work for them. You can go beyond routers with this idea. Any network-based system encrypts communications, not storage. In any such system, there is some point at which the data are in the clear. Even if the encryption is done end-to-end, the data are in the clear on the workstations, and a workstation may very well be administered by somebody other than its end user. If the administrator of the encrypting system is anybody other than the person who's to be watched, then the administrator can be approached to get the data, without alerting the target. This obviously fails when the target runs her own system. Law enforcement cares about this case. However, this case is *not* common in the market into which Cisco sells encryption. We don't even have a product that does encryption on an end node. Networks that have routers doing encryption are so rarely managed personally by the people actually under surveillance that we believe that case can be ignored. What we're saying is that, as far as *our* products are concerned, law enforcement can already get what it wants. All it has to do is go to a network administrator with a warrant. We are already in compliance with the government's stated requirements. We therefore see it as unnecessary for us to do any fancy key recovery or back doors. The same applies to many other companies' products... even in an NT network, the administrator really has control over all the PCs. You may claim that such centrally-managed systems are inherently less secure than personally-managed systems. In the real world, however, it's improbable that a large organization would get better security by letting every nontechnical user try to configure her own encryption. In any case, such systems are very common, and they form the overwhelming bulk of our market. The Doorbell concept obviously doesn't apply to truly personal machines. We're going to let the people who write software for those machines deal with that problem for themselves. I'm not sure whether we're making that easier or harder... probably, on the whole, we're leaving the difficulty about the same. In any case, we can't solve every problem in the world, but we can help our customers to protect their own security, and we can do that with products that comply with existing standards and interoperate with other people's stuff. It so happens that we have a white paper out on this. See http://www.cisco.com/warp/public/146/july98/2.html -- John B.