15 July 1998

To: cypherpunks@cyberpass.net
Subject: Ding dong! Facts calling! (Private Doorbell)
Date: Wed, 15 Jul 1998 17:49:16 -0600
From: John Bashinski <jbash@cisco.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

      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


                                        -- John B.