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
          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.