Network Working Group IAB Request for Comments: 2804 IESG Category: Informational May 2000 IETF Policy on Wiretapping Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.
AbstractThe Internet Engineering Task Force (IETF) has been asked to take a position on the inclusion into IETF standards-track documents of functionality designed to facilitate wiretapping. This memo explains what the IETF thinks the question means, why its answer is "no", and what that answer means.
connections across the Internet are as well known as possible. At the present stage of our ignorance this means making them as free from security loopholes as possible. - The IETF believes that in the case of traffic that is today going across the Internet without being protected by the end systems (by encryption or other means), the use of existing network features, if deployed intelligently, provides extensive opportunities for wiretapping, and should be sufficient under presently seen requirements for many cases. The IETF does not see an engineering solution that allows such wiretapping when the end systems take adequate measures to protect their communications. - The IETF believes that adding a requirement for wiretapping will make affected protocol designs considerably more complex. Experience has shown that complexity almost inevitably jeopardizes the security of communications even when it is not being tapped by any legal means; there are also obvious risks raised by having to protect the access to the wiretap. This is in conflict with the goal of freedom from security loopholes. - The IETF restates its strongly held belief, stated at greater length in [RFC 1984], that both commercial development of the Internet and adequate privacy for its users against illegal intrusion requires the wide availability of strong cryptographic technology. - On the other hand, the IETF believes that mechanisms designed to facilitate or enable wiretapping, or methods of using other facilities for such purposes, should be openly described, so as to ensure the maximum review of the mechanisms and ensure that they adhere as closely as possible to their design constraints. The IETF believes that the publication of such mechanisms, and the publication of known weaknesses in such mechanisms, is a Good Thing.
industry of how to build and manage such features. Some traditional telephony standards organizations have supported this by adding intercept features to their telephony-related standards. Since the future of the telephone seems to be intertwined with the Internet it is inevitable that the primary Internet standards organization would be faced with the issue sooner or later. In this case, some of the participants of one of the IETF working groups working on a new standard for communication between components of a distributed phone switch brought up the issue. Since adding features of this type would be something the IETF had never done before, the IETF management decided to have a public discussion before deciding if the working group should go ahead. A new mailing list was created (the Raven mailing list, see http://www.ietf.org/mailman/listinfo/raven) for this discussion. Close to 500 people subscribed to the list and about 10% of those sent at least one message to the list. The discussion on this list was a precursor to a discussion held during the IETF plenary in Washington, D.C. Twenty-nine people spoke during the plenary session. Opinions ranged from libertarian: 'governments have no right to wiretap' - to pragmatic: 'it will be done somewhere, best have it done where the technology was developed'. At the end of the discussion there was a show of hands to indicate opinions: should the IETF add special features, not do this or abstain. Very few people spoke out strongly in support for adding the intercept features, while many spoke out against it, but a sizable portion of the audience refused to state an opinion (raised their hands when asked for "abstain" in the show of hands). This is the background on the basis of which the Internet Engineering Steering Group (IESG) and the Internet Architecture Board (IAB) was asked to formulate a policy.
1. Without the sending party knowing about the third party 2. Without any of the recipient parties knowing about the delivery to the third party 3. When the normal expectation of the sender is that the transmitted information will only be seen by the recipient parties or parties obliged to keep the information in confidence 4. When the third party acts deliberately to target the transmission of the first party, either because he is of interest, or because the second party's reception is of interest. The term "party", as used here, can refer to one person, a group of persons, or equipment acting on behalf of persons; the term "party" is used for brevity. Of course, many wiretaps will be bidirectional, monitoring traffic sent by two or more parties to each other. Thus, for instance, monitoring public newsgroups is not wiretapping (condition 3 violated), random monitoring of a large population is not wiretapping (condition 4 violated), a recipient passing on private email is not wiretapping (condition 2 violated). An Internet equivalent of call tracing by means of accounting logs (sometimes called "pen registers") that is a feature of the telephone network is also wiretapping by this definition, since the normal expectation of the sender is that the company doing the accounting will keep this information in confidence. Wiretapping may logically be thought of as 3 distinct steps: - Capture - getting information off the wire that contains the information wanted. - Filtering - selecting the information wanted from information gathered by accident. - Delivery - transmitting the information wanted to the ones who want it. The term applies to the whole process; for instance, random monitoring followed by filtering to extract information about a smaller group of parties would be wiretapping by this definition. In all these stages, the possibility of using or abusing mechanisms defined for this purpose for other purposes exists.
This definition deliberately does not include considerations of: - Whether the wiretap is legal or not, since that is a legal, not a technical matter. - Whether the wiretap occurs in real time, or can be performed after the fact by looking at information recorded for other purposes (such as the accounting example given above). - What the medium targeted by the wiretap is - whether it is email, IP telephony, Web browsing or EDI transfers. These questions are believed to be irrelevant to the policy outlined in this memo. Wiretapping is also sometimes called "interception", but that term is also used in a sense that is considerably wider than the monitoring of data crossing networks, and is therefore not used here.
- Experience shows that human factors, not technology per se, is the biggest single source of such vulnerabilities. What this boils down to is that if effective tools for wiretapping exist, it is likely that they will be used as designed, for purposes legal in their jurisdiction, and also in ways they were not intended for, in ways that are not legal in that jurisdiction. When weighing the development or deployment of such tools, this should be borne in mind.
These things taken together mean that while wiretapping is an efficient tool for use in situations where the target of a wiretap is either ignorant or believes himself innocent of wrongdoing, Internet-based wiretapping is a less useful tool than might be imagined against an alerted and technically competent adversary.
[RFC 1984] IAB and IESG, "IAB and IESG Statement on Cryptographic Technology and the Internet", RFC 1984, August 1996.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.