Subject: RISKS DIGEST 15.55 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Tuesday 15 February 1994 Volume 15 : Issue 55 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: YAMIC [Yet Another Mistaken Identity Case] (Robert Herndon) William Safire on Clipper: ESSAY: SINK THE CLIPPER CHIP Over 10,000 Sign Petition to Oppose Clipper (Dave Banisar) Canada to monitor phone calls,fax,etc.? (Sahel Alleyasin) No switch on new Sun Microphone (Olin Sibert) Electronic Mail vs Paper Mail (mathew) FIRP report comments (Stephen D Crocker) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Tue, 15 Feb 94 14:50:59 MST From: rh@craycos.com (Robert Herndon) Subject: YAMIC [Yet Another Mistaken Identity Case] Excerpted from the Minneapolis Star and Tribune, Sunday, Feb. 13, 1994. THE RIGHT NAME, THE WRONG MAN Freed after a month in jail, innocent man found he'd lost job, van, and girlfriend. By Margaret Zack, Staff Writer Maintenance worker Russ Hamilton tried for more than a month to convince authorities that he wasn't truck driver Russ Hamilton, who was wanted for fraud. .... His troubles began Nov. 28 at a Salt Lake City party that got out of hand. Police were called, and Hamilton was arrested on two misdemeanor charges. In a routine check, police found there was a warrant out for a Russell Hamilton in Wisconsin, and both men had the same birth date. So Hamilton sat in jail. ... Dane County deputies flew to Salt Lake City and took him to Wisconsin on Dec. 19. He remained jailed, always protesting his innocence, until Dec. 30, when authorities learned they had the wrong man and released him. ... the evidence that freed him -- a photo of the man wanted on the fraud charges -- had been in the prosecutor's file all along. Hamilton, and his attorney Alan Albrecht of Brooklyn Center, said last week that someone had obtained Hamilton's birth date and gotten a driver's license in his name. They said they don't know how that occurred. The fraud suspect has reportedly been identified but is not in custody. What Albrecht finds so appalling about the case is that the photo of the real person wanted in Wisconsin was always in the prosecutor's file. "The picture could have been faxed out to Salt Lake City," he said. Or at least the deputies who flew to Utah could have taken the photo with them to be sure they had the right suspect, he said. ... But the prosector told him those would have been "extraordinary" measures and weren't warranted in the case, Albrecht said. The Dane county prosecutor who handled the case did not return repeated phone calls last week. [The article goes on to detail differences between Hamilton and the man wanted for fraud: Hamilton is 37, 5'9", heavy, with long hair, a goatee, and tattoos on his arms. The man wanted for fraud is over 6' tall, thin, and in his 50s. In addition, while Hamilton was in jail, authorities seized his van and its contents and sold them. His girlfriend, with whom he shared an apartment, moved out, and he hasn't been able to locate his clothes, furniture, or other possessions. He is now living in Minneapolis with a brother, and is preparing a civil lawsuit. The risks of technology here are apparent and familiar to RISKS readers. In this case, too, technology would seem able to have provided reasonable safeguards. That a simple check would be regarded as "extraordinary" seems itself extraordinary, but alas, is all too common. [Here is a case where checking the SSN might have helped -- except that the RISKS archives contain several cases of two people with the same name who were accidentally assigned the same SSN! PGN] ------------------------------ Date: Tue, 15 Feb 94 10:40:52 PST From: "Peter G. Neumann" Subject: William Safire on Clipper: ESSAY: SINK THE CLIPPER CHIP The Op-Ed page (A13) of the National Edition of The New York Times on 14 Feb 1994 had a piece by William Safire that is worth ferreting out. Three paragraphs (excerpted out of 15) summarize his message: To the tune of ``I Got Algorithm,'' the Eavesdrop Establishment is singing that it will help us protect our privacy but not from intrusion by the Feds. In effect, its proposal demands we turn over to Washington a duplicate set of keys to our homes, formerly our castles, where not even the king in olden times could go. Tomorrow's law enforcement and espionage cannot be planned by people stuck in the wiretap and Big Ear mind set of the past. The new Ultra secret is that the paradigm has shifted; encryption has overcome decryption. Cash in your clipper chips, wiretappers: you can't detect the crime wave of the future with those old earphones on. ------------------------------ Date: Tue, 15 Feb 1994 13:42:29 -0500 From: Dave Banisar Subject: Almost 15,000 Sign Petition to Oppose Clipper Washington, DC February 15, 1994 (second edition) Computer Professionals for Social Responsibility (CPSR) ALMOST 15,000 HAVE SIGNED PETITION TO OPPOSE CLIPPER In only two weeks, almost 15,000 users of the nation's computer networks have signed the CPSR petition calling for President Clinton to withdraw the Clipper proposal. Opposition has been widespread, from CEOs of large firms to college students in small towns, from librarians and civil libertarians to computer programmers and product marketers. To sign the petition, email with the message "I Oppose Clipper". [See Banisar, RISKS-15.44 for the petition. PGN] In 1990, over 30,000 people sent email message to Lotus asking that a product containing detailed personal information called "Marketplace" be withdrawn. Eventually Lotus withdrew the product. CPSR is a non-profit, membership organization based in Palo Alto, CA. CPSR's mission is to provide analysis of the effects of new technological developments on society. For more information, please email cpsr@cpsr.org or call 415-322-3778. [MODERATOR's NOTE: Many contributions have been received on escrowed keys, Clipper, et al. Some are repetitions of what has already been included, others are full of ad hominem comments and not appropriate for RISKS. There are also some messages that are lengthy interstitiations of already too-long messages. You will all appreciate that I am having to moderate much more stringently than usual. But the overwhelming majority of E-mail is opposed to EES/Clipper, and in support of the CPSR petition. PGN] ------------------------------ Date: 15 Feb 1994 23:41:17 GMT From: eng350q3@csulb.edu (Sahel Alleyasin) Subject: Canada to monitor phone calls,fax,etc.? Canadian security intelligence services is trying to make equipment to keep records of all conversations from millions of airborne phone, fax, radio signal and other transmissions. The first thing that comes to my mind from this high-tech snoop gadget is that it violates the people's trust and confidence. Nobody can ever be confident to have a private conversation with others. They are always afraid of what have been said because the government keeps records of these conversations. This monitoring of phone calls is the invasion of privacy. As we have read from the other examples in the text book about risk_forum digest contributions, the computers could make mistakes. In the case of Canadian government, using computers could cause someone else to be accused by the government for something he/she didn't do. An error could result, for example, from two persons having the same name. The other risk factor could be the possibility of an intruder accessing a system and erasing some of the data or other information. An intruder changing the data could cause other people to be at risk. Computers are not always to be credited. They could make errors, or someone else could cause these errors by changing the data. This hardware on Canadian security service will have the same problem, but the main issue is that the Canadian government is taking advantage of the new technology to invade people's private life. ------------------------------ Date: Tue, 15 Feb 94 09:47:11 EST From: Olin Sibert Subject: No switch on new Sun Microphone A recent product announcement from Sun Microsystems (SunFLASH Vol 62 #8, 4 February 1994) introduces "new microphone, SunMicrophone II, to ship with current and new Sun desktop platforms". Among the features described by the announcement for this "uni-directional microphone which allows greater focus on direct voice input while providing less interference from background ambient noise" is the following Q&A: Q. Does the SunMicrophone II look similar to the SunMicrophone? A. No, the two products look very different. The current SunMicrophone has a unique square shape, with an on/off switch. The SunMicrophone II looks like a classic microphone on a rectangular stand, with no on/off switch. Both products come in Sun colors and with Sun logo. So, the new, "improved" model has no "on/off" switch, although the old one did. Maybe the new microphone is "uni-directional", but that doesn't mean it can't pick up ambient sound--just turn up the gain. This "improvement" makes it all the more difficult to follow the final recommendation of CERT Advisory CA-93:15 (21 October 1993), quoted in part below. It's bad enough that the problem existed in the first place, but Sun has now made it worse! III. /dev/audio Vulnerability This vulnerability affects all Sun systems with microphones. ... A. Description /dev/audio is set to a default mode of 666. There is also no indication to the user of the system that the microphone is on. B. Impact Any user with access to the system can eavesdrop on conversations held in the vicinity of the microphone. C. Solution [...] *** Any site seriously concerned about the security risks associated with the microphone should either switch off the microphone, or unplug the microphone to prevent unauthorized listening. *** Even if this vulnerability is fixed from a systems viewpoint, a user is still vulnerable to Trojan horse programs that exploit the user's own (legitimate) access to the microphone--and the information discussed in a person's office may be far more sensitive than the information stored on an office computer. This is especially a problem for multi-level secure (MLS) systems. Although MLS systems offer protection against disclosure of information by Trojan horse programs, that's no help at all if the microphone picks up a Top Secret conversation that occurs in the office while the user happens to be logged in at Unclassified. Sure--one might look around to be sure there's nobody who can inadvertently overhear, or close the office door--but the computer? Computers don't eavesdrop, do they? Computer manufacturers need to address these risks. It's certainly nifty to have desktop audio- and video-conferencing, but not when that equivalent to installing a bug in every office (and remember not to aim your video camera at the whiteboard). Every microphone and video camera should have a positive on/off switch and some positive indication (such as a light) to show when it's actually in use (as opposed to just being enabled by the on/off switch). The broadcast industry learned this years ago, with its "ON THE AIR" lights. Fail-safes, such as permitting only manual activation, but computer deactivation, or requiring manual confirmation of any attempted activation, would be better still. Olin Sibert |Internet: Sibert@Oxford.COM Oxford Systems, Inc. |UUCP: uunet!oxford!sibert ------------------------------ Date: Tue, 15 Feb 94 13:54 GMT From: mathew@mantis.co.uk (Snakes of Medusa) Subject: Electronic Mail vs Paper Mail (RISKS DIGEST 15.53) I'd just like to disagree briefly with one of the comments made in RISKS 15.53 by Jack B. Rochester <0002757498@mcimail.com>, talking about electronic mail. He writes that "Good grammar and proper punctuation are not required in e-mail, and their absence does not seem to affect regard for that person." I must disagree with that assertion strongly. One particular case springs to mind, where I first met someone over the net. I got the impression that he was, shall we say, 'intellectually challenged'. When I eventually met him in real life, I was astounded to discover that he was quite eloquent. I had built up a very strong disregard for him, based on his appalling grammar, spelling and punctuation. That may seem unfair, but people discriminate the same way in real life, as any stutterer or stammerer will know. At the risk of being contentious, my perception is that those who claim spelling, punctuation and grammar are unimportant, generally turn out to be people who cannot spell, punctuate or string together a sentence. It's true that e-mail lacks the boilerplate formalisms of paper mail. In fact, when I get e-mail which starts "Dear Sir", it seems very odd to me. Whether the lack of generally meaningless stock phrases is a risk, I don't know. Doubtless such formalisms originally served some purpose, or else they wouldn't be there; I'm not sure that all etiquette is worth keeping in the transition from paper to screen, though. Some of it may be obsolete. Regarding notoriety, I do still find it bemusing to discover that "real people" (from TV, films and so on) have e-mail addresses. Sometimes the lack of distance and formalism one gets with e-mail can give a whole new perspective on a person. For example, I gave in to temptation and sent electronic mail to Billy Idol. He turned out to be a really nice guy, and articulate too -- absolutely not what I was expecting from a world-famous rock musician. mathew ------------------------------ Date: Tue, 15 Feb 94 17:12:30 -0500 From: Stephen D Crocker Subject: FIRP report comments -- forward to your lists if you wish Response to the Draft Report of the Federal Internetworking Requirements Panel (FIRP), 14 January 1994 Part 1: Strategic Comments Stephen D. Crocker Vice President, Trusted Information Systems, Inc. IETF Security Area Director 15 February 1994 INTRODUCTION "The Federal Internetworking Requirements Panel (FIRP) was established by the National Institute of Standards and Technology (NIST) to reassess federal requirements for open systems networks and to recommend policy on the [U.S.] Government's use of networking standards." [Preface, para 1.] The FIRP report describes the need for the U.S. Federal Government to embrace not only the OSI protocol suite but also the ubiquitous TCP/IP Protocol Suite. In fact, Internet Standards, which include the TCP/IP Protocol Suite, are in very wide use in the Government, throughout the U.S. and throughout the world. Some OSI products and systems exist, and it may be impossible to switch completely to TCP/IP-based systems. Nonetheless, the report says, it is time to acknowledge the widespread use of the Internet Standards and give formal sanction to their use in the Government. This is indeed a welcome change, and it should help the Government take better advantage of modern data networking. This memo is the first of two responses to the report. In this memo, some issues are raised with respect to the recommendations in the FIRP report, and suggestions are made for avoiding problems in the future. In the other memo, comments are given with respect to specific sections of the report. STRATEGIC COMMENTS This panel was convened in response to a divergence between the strategy the U.S. Federal Government had been following for several years and the direction of the marketplace. As the report makes clear, the divergence had become so great that the policy no longer reflected attainable objectives. The accommodation of the Internet Standards brings policy into line with widespread practice and removes obstacles for rational management decisions in the future. In this light, it's worth examining the recommendations to ascertain if they are sufficient to avoid similar problems in the future. As with any large organization, the U.S. Federal Government pursues multiple policy objectives and has ingrained organizational imperatives. Recommendations that respond only to the current marketplace without also anticipating the future or without including the flexibility to follow the lead of the marketplace may lead to the convening of a similar panel in the not too distant future. The FIRP report makes five recommendations: 1. The role of oversight and integration across federal agency internetworking activities should be strengthened within the Office of Management and Budget. 2. The roles and responsibilities for fostering standards and assessing technological change should be refocused and strengthened by the Department of Commerce. 3. The roles and responsibilities for infrastructure development and operations to support all internetworking services from advanced research and development to leading edge to core/commodity services should be clearly defined and formally assigned through the Information Infrastructure Task Force. 4. The roles and responsibilities of affinity groups should be defined, including how they are created and coordinated by the Government Information Technology Services working group. 5. In accordance with OMB Circular A-119, Revised October 1992, voluntary standards should be adopted and used by Federal agencies, and international standards should be considered in the interests of promoting trade. The current GOSIP policy should be modified by the Department of Commerce to reflect the wider range of international voluntary standards for internetworking. Recommendation 1 asks that OMB's role be strengthened. OMB has the charter to review the roles, responsibilities and performances of the various agencies which provide, develop or guide the U.S. Government's internetworking activities. This is an important role. The OMB should develop guidelines for measuring the performance of the assigned agencies and the attainment of the overall objectives. Although there is usually a preference to avoid duplication of activities, some degree of competition, exploration of alternative strategies and comparison of results is desirable because it tends to produce more cost effective products and services that are better matched to the needs of the users. Wherever feasible, the OMB should also foster multiple approaches and/or participation by multiple agencies in order to provide for maximum feedback within the system. Recommendation 2 suggests the Department of Commerce be tasked with new responsibility for "fostering standards." Presumably the context of this recommendation is with respect to internal standards within the U.S. Government. The general arena for developing Internet Standards is the Internet Engineering Task Force (IETF) which operates in conjunction with the Internet Architecture Board (IAB) under the auspices of the Internet Society. The Internet Society, along with NSF, ARPA, DOE and NASA, provide considerable financial support to the standards activities. This process enjoys wide spread support form the industrial, academic and government communities, and as a result, the standards developed in this arena reflect the needs of marketplace and are usually adopted widely and quickly. Even if this recommendation is understood to be limited to refer to internal use of the U.S. Government, the recommendation is flawed. "Department of Commerce" here certainly includes NIST, but is likely to include other parts of the Department. While NIST is indeed the federal agency tasked with promoting and developing standards, NIST and the rest of the Department have at least two difficulties to overcome. First, NIST has been the lead agency with respect to GOSIP. NIST personnel are deeply knowledgeable about the OSI suite and less familiar with the TCP/IP Protocol Suite. NIST is not now in a position to provide leadership in this area, although it does have the technical strength to follow, assist and participate in the ongoing standards activities. One challenge for NIST in the next few years will be to strengthen its staff and adjust its direction to move toward a stronger involvement in the Internet Standards activities. A significant part of this challenge is working in a standards arena in which the U.S. Government does not have de jure authority or veto power. Second, the Department of Commerce is heavily committed to a particular strategy with respect to cryptography that is currently in conflict with the forces in the marketplace. NIST is the lead agency involved in the promulgation of the Digital Signature Standard (DSS) and the "Clipper" escrowed-key encryption system. Both of these initiatives are meeting very strong resistance from industry and academia. The RSA algorithm is the de facto standard for signatures and key exchange, and some form of DES and/or some proprietary algorithms, e.g. RC2 and RC4, are likely to be the de facto standards for bulk encryption. The U.S. Government's orientation toward cryptography comes from the specific concerns of the intelligence and law enforcement agencies. While not denying the principle that the intelligence and law enforcement agencies have legitimate concerns, it is far from clear that the approach being taken by the Department in support of these concerns will be successful. In fact, it is entirely possible these initiatives will not succeed in the marketplace. If so, the result will be the existence of dual standards in which the Government algorithms will be used only under duress, both the Government and the general population will bear unnecessary costs dealing with dual standards, the introduction of strong security controls will be retarded, and the intelligence and law enforcement agencies will not succeed in preventing the use of strong encryption, except in so far as they succeed in retarding the use of encryption altogether. On February 4, 1994, the Department announced it had made substantial progress in its review of policies governing cryptography. Its announced that export controls on DES and similar cryptography will remain in place, that the Department will continue to promulgate the Digital Signature Standard despite uncertainties about the patent and licenses, and it will adopt the escrowed encryption system (Clipper) as a Government standard. Nothing in the public record supports these decisions, and it was made clear that these decisions are driven by the views of the law enforcement and intelligence agencies. The purpose of citing these controversies concerning cryptography policy here is to explicate a consequence relevant to the FIRP report. The Commerce Department, and in particular NIST, have a conflict of interest. Like a lawyer with two clients with intertangled interests, the Department is trying to serve two constituencies. One constituency is the federal government as a whole, and in that role, it must do the best job it can of interpreting the market forces and adopting federal standards that are consistent with the marketplace. The Department's other constituency is the particular needs of the law enforcement and intelligence agencies. Those agencies desire to influence and change the direction of the marketplace. In service of this role, NIST is adopting federal standards that reflect the direction the law enforcement and intelligence agencies want the market to go. The only way for the Department to be successful is if the law enforcement and intelligence agencies prevail and the marketplace adopts the standards the Government is promulgating. Perhaps this will happen, and if so, the Government's gamble will pay off. However, if the marketplace continues to adopt RSA as the preferred public key algorithm, if DES and other non-escrowed algorithms are used for symmetric key encryption, and if products with encryption are become prevalent in non-U.S. markets, not only will the stated goals of the law enforcement and intelligence communities be lost, the rest of the federal government and indeed the rest of the country will have paid the price in struggling with dual standards. Like a stubborn child with a tensed jaw, the U.S. Government seems bent on pressing forward with these initiatives. So be it. But in handing out accolades because NIST is now willing to accommodate the protocols that have been commonplace for many years, it's fair to note that NIST and the rest of the Department are engaged in an exercise which promises to bring a repeat of the same divergence, confusion and waste of resources which the FIRP report documents. Recommendation 3 suggests that each role and responsibility should be tasked to some specific agency. Apparently this is aimed at reducing duplication. While useful in principle, this approach is fragile. If the assigned agencies are incompetent or inefficient, everyone suffers. The report does suggest that some assignments may be decentralized. Decentralization should be emphasized. Wherever possible, multiple approaches and multiple agencies should be encouraged. Competition and comparison are enormously useful forces. As noted above with respect to recommendation 1, the OMB should encourage as much decentralization as possible and should oversee the agencies establishing a means of measuring the results. Recommendations 4 and 5 are oriented toward implementation of the first three recommendations and raise fewer strategic concerns except that recommendation 5 implicitly acknowledges that the role of the U.S. Government in the standards process shift from one of controlling the process to one of participating in the process. As noted above with respect to recommendation 2, this shift poses an institutional challenge for the Government in general and NIST in particular. ------------------------------ Date: ongoing From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. ARCHIVES: "FTP CRVAX.SRI.COMlogin anonymousYourName CD RISKS: GET RISKS-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is vital. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 15.55 ************************