Text File

Subject: RISKS DIGEST 14.63 REPLY-TO: risks@csl.sri.com

RISKS-LIST: RISKS-FORUM Digest Tuesday 18 May 1993 Volume 14 : Issue 63

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents: Read any good magazines lately? (Robert M. Slade [copyrighted article]) Re: Cut and Paste risks (Pete Mellor, Byron Rakitzis, Tim Cook, Christopher Lishka, Joseph Hall) Re: CHI & the Color-blind? (Eric Haines, Tom Ohlendorf, David Tarabar) Re: Denning on NIST/NSA Revelations (Dorothy Denning) Re: NIST's reply to Bidzos (Jim Horning, Frederick Roeber, Jim Sims, Chris Phoenix, Carl Ellison) Compromising the escrow agencies (Mickey McInnis)

RISKS Forum is a moderated digest discussing risks; comp.risks is its Usenet counterpart. Undigestifiers are available throughout the Internet, but not from RISKS. Contributions should be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with appropriate, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. REQUESTS please to RISKS-Request@CSL.SRI.COM.

Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR> CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 14, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". <CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.

For information regarding delivery of RISKS by FAX, phone 310-455-9300 (or send FAX to RISKS at 310-455-2364, or EMail to risks-fax@vortex.com).

ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

----------------------------------------------------------------------

Date: Tue, 18 May 93 12:42:47 PDT From: rslade@sfu.ca Subject: Read any good magazines lately? [with permission, for RISKS]

Memoirs of a (media star) virus researcher [MEMOIR7.CVP 930515]

I have been known, from time to time, to make rather unkind statements about the accuracy of virus reports in the mainstream media. Some of my antipathy arises simply from the fact that there is an awful lot of "mythology" surrounding viral programs, and most of the pieces that appear in the media simply perpetuate this. Some of my experience, however, is first hand.

I like live radio best, and TV news the worst. "Live" anything gives you a bit of control, whereas TV is, in my view, arrogant, sensational and overpaid. However, the electronic media still doesn't have an "all-computer" channel, so most of the media reports about viral programs happen in print media. I've had a few forays there as well, but would like to outline one recent experience.

A reasonably prominent periodical devoted to security topics has been advertising for writers in, among other areas, the virus field, so I sent some sample materials off. I did not hear anything for about eight months, and then got a call asking me to do an article. On groupware. Well, OK, regardless of the topic I can use the money. Only there isn't very much money slated for this, slightly under $400 for roughly three pages of material. (Please have it ready in 20 days.) It doesn't take long, at that price, for the "rate per hour" to drop into the basement.

However, it is not enough to write the article. No, one has to contact the vendors, and hear what they have to say on the topic. This, actually, consumes the most time. Some research, and roughing out an outline, took up two hours. A rough draft took three. Polishing the final draft took about an hour. Lots of room for profit there. (Of course, when you consider the years it takes to build the background to be able to do that, it tends to reduce the margin a bit ... :-) But contacting three consultants, two user group representatives, and eleven representatives from seven major vendors took more than fourteen hours spread over a ten day period. In the end it got me one very helpful vendor contact (Carol Smykowski from Fischer International, very nice lady), one returned message, one faxed spec sheet from a loosely related product and a heavy parcel that arrived postage due after the deadline. Needless to say, this was less than helpful to the project.

In the end, the article was rejected. Not enough "vendor quotes".

However, is my whining and complaining of any importance to you? Well, yes, it is. What is really important here is the fact that most of the articles being generated in the "trade press" are, by and large, "infomercials" on the printed page. Articles are being written, by people who, if they have a technical background at all, are writing out of their field, and are being judged on the acceptability of the content to vendors and advertisers. The vendors, quite happy with the situation, are in no hurry to be helpfully involved in the process (or, indeed, even to return phone calls).

(As two examples, I cite the recent (as this is written) releases of PKZip 2.04 and MS-DOS 6.0. For the first month after the release of the new PKZip, while the nets were stretched by the reports of the various bugs, and the latest release by PKWare to try to correct them, PC Week blithely rhapsodized over "version 2" and advertised that it had version 2.04c (the real buggy one) on its own board. Meanwhile, in spite of the protests of the virus research community *before* MS-DOS 6 was released, and the almost immediate storm of reports of bugs and problems with various of the new features, the trade press is only now, after six weeks of ecstatically positives reviews of MS-DOS 6, starting to report some of the potential problems.)

The primary distribution of this article will, of course, be the Internet, as it is also my primary source of information. Unfortunately, the population of "the net" is likely around two to five million. A large number, perhaps, but very small in comparison to the estimated hundred million PC users alone. And in that "larger" world, the inaccurate "non-net" media tends to hold much more importance.

copyright Robert M. Slade, 1993 MEMOIR7.CVP 930515

Vancouver Institute for Research into User Security Canada V7K 2G6 ROBERTS@decus.ca Robert_Slade@sfu.ca rslade@cue.bc.ca p1@CyberStore.ca

------------------------------

Date: Tue, 18 May 93 10:12:06 BST From: Pete Mellor <pm@cs.city.ac.uk> Subject: Re: Cut and Paste risks (Zwicky, RISKS-14.62)

Elizabeth Zwicky's report (RISKS-14.62) about cut and paste with the elbow reminded me of the "Case of the Overhanging Data Entry Operator", an anecdote which caused some amusement many years ago in the customer support department of one of the British manufacturers of mainframe computers, for whom I then worked.

In those days, keying data directly onto disk, instead of punching onto cards first, was relatively new, and "Direct Data Entry" was a selling point. The DDE station was an intelligent terminal with disk, screen and keyboard. The operator used to log in giving a password.

There was a fault in the password handling whereby a leading space would be accepted as part of the password when this was set, but leading spaces were ignored when the password was keyed at login. The temporary work-around was, obviously, not to use spaces in passwords.

On one site, the support engineers were puzzled to find that, despite this advice, the fault was being repeatedly triggered on one DDE station, although the operator concerned emphatically denied having pressed the space bar when entering a new password.

The proximal cause turned out to be that the operator was a well-built woman ...

Peter Mellor, Centre for Software Reliability, City University, Northampton Sq., London EC1V 0HB, Tel: +44(0)71-477-8422, JANET: p.mellor@city.ac.uk

------------------------------

Date: Mon, 17 May 93 21:54:46 PDT From: netapp!byron@netcom.com (Byron Rakitzis) Subject: Subject: Re: Cut and Paste risks (Zwicky, RISKS-14.62)

While the X method for cut and paste may be poorly designed, I think there is another RISK associated with system admin using window systems: namely, the tendency to leave a window open with the root account logged in. I don't mean to sound holier-than-thou, but it was always my practice to limit my actions as root to as few as possible, by always explicitly su-ing to root, performing a task, and logging out again. While this does not eliminate the aforementioned risk, it does tend to minimize it.

Byron Rakitzis. <byron@netapp.com>

------------------------------

Date: 18 May 1993 15:49:59 +1000 From: tim@deakin.edu.au (Tim Cook) Subject: Re: Cut and Paste risks (Zwicky, RISKS-14.62)

I think the advantages of cut-and-paste with X clients far outweigh such a potential problem.

We should identify the main source of the risk, which in my opinion is general access to super-user privileged shells. This can be greatly reduced by employing one of those utilities that provide individual super-user privileged commands to specific users from their own accounts. It would be much harder to paste something that did damage in this scenario.

Tim Cook, Systems Engineer, Deakin University.

------------------------------

Date: Tue, 18 May 1993 11:22:57 GMT From: lishka@dxcern.cern.ch (Christopher Lishka) Subject: Re: Cut and Paste risks (Zwicky, RISKS-14.61)

>I've never liked the X method of cutting and pasting much, >but I'm beginning to feel actively hostile towards it. > Elizabeth D. Zwicky zwicky@erg.sri.com

Not to mention mixed platform, mixed GUI cut-and-paste problems. I am a system manager for both VMS and Ultrix systems. I use an Ultrix machine running Motif for my GUI, while most of the VMS users have DECwindows.

The main problem is the differing cut-and-paste buttons: Motif uses the middle button, while DECwindows uses the right button (assuming a right-handed mouse set-up). This becomes a problem when I run a standard DECwindows applications with the display on Motif. Only the left mouse button (select text) remains constant.

Plus, some DECwindows applications (notably DECwindows Mail) like to reset the cut-and-paste buffer if you switch input focus to a certain window. (E.g., DECwindows Mail seems to put the text of the current message in the cut-and-paste buffer automatically.) My autofocus mouse (ala Sun) wreaks havoc with this. Many times I have selected text in one window, moved the mouse to a terminal window, pasted, and had the entire contents of a mail message run as Unix commands because I had accidentally had my mouse cross over the DECwindows Mail window (focusing input briefly on it).

My solution? Live with it. It has not gotten to a point yet where I feel the need to hunt down the various settings files (*if* this is possible) to fix the problems by creating "Lishka's own standard GUI set-up". Being a system manager, I use a good variety of computers and their various GUIs frequently. Furthermore, I have to help users a lot, and I have found that if I customize my own GUI and shell settings too much, then I can't function with the standard GUI and shell commands. (It is very embarrassing to type all of these arcane short-cut aliases in front of a user at her/his terminal, and have them not work! You look incompetent....)

How to practice safe cut-and-paste practices? *NEVER* paste into a terminal window with a superuser session (be it "SYSTEM" or "root"). This means one has to type it all, possibly leading to transcription errors, but one should always double-check important commands anyway.

Of course, as Ms. Zwicky's message shows, a lot of times pasting into a superuser session window is unintentional. More than once I have gone to scroll my xterm window (using the middle button in the scroll-bar area), only to hit the middle button a microsecond too early. BLAM! I've just pasted a mail message into my VMS SYSTEM session, and all of its contents are being interpreted as commands. Luckily nothing major has happened because of this!

Sometimes I think going back to a good old VT100 terminal would be safer all around....

Christopher Lishka PPE Division, CERN lishka@dxcern.cern.ch

------------------------------

Date: Tue, 18 May 1993 14:37:36 -0700 From: Joseph Hall <Joseph_Hall@motsat.sat.mot.com> Subject: Re: Cut and Paste risks (Zwicky, RISKS-14.62)

The Macintosh Programmer's Workshop (MPW) shell provides an interesting solution to this problem ... you execute a line of text as a command by pressing the ENTER key (on the numeric keypad). RETURN simply inserts a carriage return in the text. Similarly, pasted text isn't interpreted as commands to be executed.

I wouldn't mind it at all if xterms, cmdtools etc. worked this way. I've yet to experience disaster as a result of X pasting, but I've come close.

Joseph Nathan Hall, Software Systems Engr, GORCA Systems Inc. jnhall@sat.mot.com joseph@joebloe.maple-shade.nj.us (609) 732-3194

------------------------------

Date: Tue, 18 May 93 10:22:58 -0400 From: Eric Haines <erich@eye.com> Subject: re: CHI & the Color-blind? (Yu, RISKS-14.62)

An article which color interface designers would benefit from reading:

Gary W. Meyer and Donald P. Greenberg, "Color-defective vision and computer graphics displays", IEEE Computer Graphics and Applications, v. 8, n. 5, Sept 1988, p. 28-40.

It discusses how to select colors which are appropriate for the various types of color blindness, along with reasonable general solutions.

Eric Haines

------------------------------

Date: Tue, 18 May 1993 08:08 EDT From: "Tom Ohlendorf - TSU Admin. DP, (410) 830-3642" <D7AP002@TOA.TOWSON.EDU> Subject: Re: CHI & the Color-blind?

> "A black icon facing left to right means a call was placed, but no > contact was made. A red icon facing left to right means a call was > placed and contact was made, but a promise to pay was not received. > A green icon facing left to right means a promise to pay was arranged. > An icon facing right to left means the debtor called the collector."

Not only are the color blind affected by the new monitors, so are the dyslexic. I can very easily see a dyslexic person interpreting a right to left icon as left to right. Suppose the person is color blind and dyslexic....

Tom Ohlendorf, Programmer/Analyst, Towson State University, Towson, MD 21204 OHLENDORF-T@TOA.TOWSON.EDU (410) 830-3642

------------------------------

Date: Tue, 18 May 93 15:26:14 -0400 From: dtarabar@hstbme.mit.edu (David Tarabar) Subject: RE: CHI & the Color-blind?

The CHI community is aware of the potential problems that Vannevar Yu has pointed out. For example, the Macintosh User Interface Guidelines has 8 pages devoted to the use of color in applications. They urge developers to "Always develop for black and white first and then colorize that design". They point out that to accommodate "people with color-deficient vision", "you shouldn't use color as the only means of communicating important information. Color should be used redundantly."

I'm sure that other user interface guidelines and texts make similar points. Perhaps the risks here are that applications developers are not aware of (or ignore) the literature about human interface design.

Dave Tarabar dtarabar@hstbme.mit.edu

------------------------------

Date: Tue, 18 May 93 16:54:22 EDT From: denning@cs.cosc.georgetown.edu (Dorothy Denning) Subject: Re: Denning on NIST/NSA Revelations (Sobel, Denning, Rotenberg)

In response to David Sobel's statement about NIST and the DSS, I wrote in RISKS-14.60:

... NIST issued the DSS proposal along with a public call for comments as part of their normal practice with proposed standards. The community responded, and NIST promptly addressed the security concerns. Among other things, the DSS now accommodates longer keys (up to 1024 bits). As a result of the revisions, the DSS is now considered to be just as strong as RSA.

In RISKS 4.62, Marc Rotenberg responded:

Denning has to be kidding. The comments on the proposed DSS were uniformly critical. Both Marty Hellman and Ron Rivest questioned the desirability of the proposed standard.

One of the reasons for the concern was the secrecy surrounding the development of the standard. The documents disclosed by NIST and NSA to CPSR make clear that NSA used its classification authority to frustrate the attempt of even NIST's scientists to assess the candidate algorithm.

The DSS is similar to a scheme by El Gamal, which was presented at CRYPTO 84 and subsequently published in the IEEE Trans. of Information Theory (July 85). It is even closer to a scheme by Schnorr, which was presented at CRYPTO 89. The DSS is not classified and the basic approach has been under scrutiny by the crypto community since 84. All of the cryptographers that I have spoken with at NIST have made the assessment that the DSS (as revised in response to the comments by Hellman, Rivest, and others) is at least as strong as RSA for comparable key lengths. I am unaware of any evidence to the contrary.

Also in RISKS-14.62, Bill Murray wrote

While it may be true that DSS with a 1024 bit modulus is as secure for digital signatures as RSA, it does not meet either the congressional mandate or the requirement. The congressional mandate was for a public-key standard, not for a digital signature standard. The requirement is for a mechanism for key exchange.

According to NIST, there was no Congressional mandate for a public-key standard. Congress did give NIST the charge to develop standards for sensitive, unclassified information, but it left open to NIST exactly what those standards should be. On its own initiative, NIST issued a solicitation for a public-key standard in the Federal Register, June 30, 1982. My understanding is that the solicitation was very broad and did not identify exactly what functions such a standard would need to provide. Several years later NIST, at their discretion, proposed the DSS.

In retrospect, we can now look back and see how the DSS fits in with Clipper and Capstone. The result will be a complete package that has encryption, signatures, and key management/exchange. Thus, the advantage of RSA over the DSS in its ability to do key exchange disappears.

It is very easy to be critical of a process when you are looking at it from the "stands" instead of the "court" and from hindsight rather than from current action and concerns.

Dorothy Denning

------------------------------

Date: Tue, 18 May 93 11:22:55 -0700 From: horning@src.dec.com Subject: Re: NIST's reply to Bidzos (RISKS-14.62)

Ed Roback's last sentence is the zinger, in terms of revealing the state of mind of those involved in this effort:

...and of the law enforcement community for continued legal access to the communications of criminals.

What ever happened to "innocent until proved guilty"?

Also, Clipper is only mandated for government use (he says). I'm all in favor of exposing criminals in government, but is this really the most cost-effective way?

Jim H.

------------------------------

Date: Tue, 18 May 1993 10:56:42 GMT From: roeber@vxcrna.cern.ch (Frederick Roeber) Subject: Re: NIST's reply to Bidzos (RISKS-14.62)

They mean "suspects", not "criminals", don't they?

------------------------------

Date: Tue, 18 May 93 08:49:06 EDT From: sims@pdesds1.atg.trc.scra.org (Jim Sims) Subject: Re: NIST's reply to Bidzos (RISKS-14.62)

>> NSA's analysis on the security >> risks of the escrow system is not available for public >> dissemination. >> >>> >>>> NIST: It will not be possible for anyone from Mykotronx, VLSI, >> NIST, NSA, FBI (or any other non-escrow holder) to >> compromise the system.

Really? Then why is the NSA/NIST/etc *so* reluctant to release details of the system? Details that are certainly known (piecemeal) to the *anyone*s mentioned above.

>> To prevent this, it >> is envisioned that every time a law enforcement agency is >> provided access to the escrowed keys there will be a record >> of same referencing the specific lawful intercept >> authorization (court order). Audits will be performed to >> assure strict compliance. This duplicates the protection >> afforded nuclear release codes. If additional escrow >> agents are added, one additional person from each would be >> required to compromise the system. >> >>> >>>> NIST: No. First of all, there is strict and limited use of >> subpoenaed material under the Federal Rules of Criminal >> Procedure and sanctions for violation. There has been no >> evidence to date of Governmental abuse of subpoenaed >> material, be it encrypted or not. Beyond this, other >> Federal criminal and civil statutes protect and restrict the >> disclosure of proprietary business information, trade >> secrets, etc. Finally, of all the Federal agencies cited, >> only the FBI has statutory authority to conduct authorized >> electronic surveillance. Electronic surveillance is >> conducted by the FBI only after a Federal judge agrees that >> there is probable cause indicating that a specific >> individual or individuals are using communications in >> furtherance of serious criminal activity and issues a court >> order to the FBI authorizing the interception of the >> communications.

You just *don't* get it, do you? You can make all the laws you want. You *CANNOT* force anyone to comply with them.

And all the assurances you can give about due process and Federal judges agreeing, etc doesn't hold water. What Federal judge agreed to the ATF/FBI sponsored stupidity in Waco Texas recently?

As we have already seen severe erosion of the 'unwarranted search and seizure' protection for the sake of the phony War on Drugs, how can you expect anyone to believe the same thing wont happen on a much larger scale. It's *so* much easier to search electronic communications than someone's car.... Just ask the NSA.

And speaking of "only after a Federal judge agrees" it seems like you just introduced a SINGLE failure point into the marvelous triple-lock system so cleverly crafted....

skeptical, jim

------------------------------

Date: Tue, 18 May 1993 22:28:16 GMT From: efi!chrisp@uunet.UU.NET (Chris Phoenix) Subject: Re: NIST's reply to Bidzos (RISKS-14.62)

I have put together a few sentences from NIST. Together they paint a rather scary picture. I don't think I've changed any meanings by taking anything out of context.

>>>>> NIST: There are no current plans to legislate the use of Clipper. > .... The > option for legislation may be examined during the policy > review ordered by the President. >>>>> NIST: .... We also > point out that the President's directive on "Public > Encryption Management" stated: "In making this decision, I > do not intend to prevent the private sector from developing, > or the government from approving, other microcircuits or ^^ > algorithms that are equally effective in assuring both ^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ > privacy and a secure key-escrow system." ^^^^^^^^^^^^^^^^^^^^^^^^ > >>>>> NIST: You are correct that, currently, Clipper Chip functionality > can only be implemented in hardware. We are not aware of a > solution to allow lawfully authorized government access when > the key escrow features and encryption algorithm are > implemented in software. ..... Existing software > encryption use can, of course, continue.

>>>>> NIST: No studies have been conducted on a government-wide basis to > estimate the costs of telecommunications security > technologies. The needs for such protection are changing > all the time.

To me it looks like the line quoted from the President's directive only protects private encryption if done in hardware. As they themselves say, there is no known way to enforce the escrow of software encryption keys. Can anyone speculate on the likely results of this "option for legislation" that the President is going to "examine"?

So my feeling from reading all this is that the government may try to legislate the use of encryption that can be implemented only in hardware. I can see it now. "Responding to privacy concerns about the Clipper chip, AT&T has privately developed a new encryption chip using a proprietary algorithm. .... 'In order to ensure that this chip will assure privacy as well as complying with new escrow laws, the algorithm has been submitted to NIST's approval process, and we have made a few changes,' says AT&T spokeswoman ...."

It would not surprise me at all if Clipper ended up in all Newtons, cordless phones, and faxes by the year 2000. This will cause someone to make incredible amounts of money. Has anyone wondered where all this money will go? I am not trying to form a conspiracy theory here--it is possible that the Clipper really was motivated by wiretaps and no one realized how many Clippers could end up being sold. But given the upcoming proliferation of wireless computers, I think this question needs to be asked now. Whatever the origins of Clipper, there is now a serious risk of corruption associated with it just from the money involved. Does anyone have hard estimates on how much additional money flow would be generated by using Clipper in all wireless computers and communication products for the next 10 years?

Chris Phoenix, chrisp@efi.com, 415-286-8581

------------------------------

Date: 18 May 1993 22:40:00 GMT From: cme@ellisun.sw.stratus.com (Carl Ellison) Subject: Re: NIST's reply to Bidzos (RISKS-14.62)

>What is the smallest number of people who are in a position to compromise the >security of the system?

>>>>> NIST: It will not be possible for anyone from Mykotronx, VLSI, > NIST, NSA, FBI (or any other non-escrow holder) to > compromise the system. Under current plans, it would be > necessary for three persons, one from each of the escrow > trustees and one who knows the serial number of the Clipper > Chip [...]

Clearly, NIST doesn't consider release of a chip's key to outside criminals by one FBI agent to be a compromise of security, if that agent got the key from the escrow agencies in a normal way. Does this mean that once a person has been subjected to a wiretap, he doesn't deserve any security -- no matter what the reason for the tap?

What of the ability of a single gov't employee illegally to declare a national security tap and by weight of authority get escrow holders to release keys? This, too, sounds like a single-source of failure.

What of the possibility of buying two people, one in each agency, to get copies of the whole database? That sounds like 2 rather than 3 to me.

>Did the administration ask these questions (and get acceptable answers) before >supporting this program? If so, can they share the answers with us? If not, >can we seek answers before the program is launched? > >>>>> NIST: These and many, many others were discussed during the > development of the Clipper Chip key escrow technology and > the decisions-making process. The decisions reflect those > discussions and offer a balance among the various needs of > corporations and citizens for improved security and privacy > and of the law enforcement community for continued legal > access to the communications of criminals.

Clearly, NIST believes that a set of meetings behind closed doors is an adequate discussion and that we the public should thank them for their effort and applaud their claimed "balance among the various needs of corporations and citizens for improved security and privacy and of the law enforcement community for continued legal access to the communications of criminals".

Whatever happened to scientists at NIST? Why does it sound like we're hearing from PR men?

Carl Ellison, Stratus Computer Inc., 55 Fairbanks Boulevard ; Marlborough MA 01752-1298 cme@sw.stratus.com TEL: (508)460-2783

------------------------------

Date: Mon, 17 May 93 23:44:48 CDT From: "McInnis, M.R. (Mickey)" <mcinnis@vnet.IBM.COM> Subject: Compromising the escrow agencies

I'm surprised that no one has commented on what I see as an obvious way to compromise the escrow agencies for Clipper.

Suppose for instance that clipper phones were already available for several years. Suppose that during the recent Waco standoff, the BATF went to some gullible federal judge and said:

"We have found that these people have got a large number of Clipper equipped phones. They keep using different phones, and it takes us hours or days to process the paperwork, contact the escrow agencies, etc. for each new phone they use.

These delays are making a dangerous situation worse and give the cultists enough time to plan actions and execute them before we can decipher the recorded conversations. It endangers the children in the compound and the law enforcement people around the compound.

We need you to sign this order that requires the two escrow agencies to release the entire set of keys to us. (Since we don't know the serial numbers of all the phones he might have.) Of course, we don't want the media and the cultists to find out about it, so there is a gag order included.

Of course, we will destroy our records once the standoff is over."

The frightening thing about this is that they only have to convince one federal judge.

Mickey McInnis mcinnis@vnet.ibm.com

------------------------------

End of RISKS-FORUM Digest 14.63 ************************