idnits 2.17.00 (12 Aug 2021) /tmp/idnits35928/draft-hardie-perpass-touchstone-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 4) being 67 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 19, 2013) is 3129 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hardie 3 Internet-Draft 4 Intended status: Informational October 19, 2013 5 Expires: April 22, 2014 7 A personal touchstone for discussions of pervasive passive monitoring 8 draft-hardie-perpass-touchstone-00 10 This document may contain material from IETF Documents or IETF 11 Contributions published or made publicly available before November 12 10, 2008. The person(s) controlling the copyright in some of this 13 material may not have granted the IETF Trust the right to allow 14 modifications of such material outside the IETF Standards Process. 15 Without obtaining an adequate license from the person(s) controlling 16 the copyright in such materials, this document may not be modified 17 outside the IETF Standards Process, and derivative works of it may 18 not be created outside the IETF Standards Process, except to format 19 it for publication as an RFC or to translate it into languages other 20 than English. 22 Abstract 24 This document contains the author's personal statement regarding 25 pervasive monitoring and it suggests a touchstone for the Internet 26 engineering community to consider in protocol and system design. 28 Status of This Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 22, 2014. 45 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 3. What is to be done? . . . . . . . . . . . . . . . . . . . . . 3 61 4. A personal touchstone . . . . . . . . . . . . . . . . . . . . 3 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1. Introduction 70 It has become public knowledge that multiple national governments 71 have severally and together engaged in pervasive monitoring of 72 Internet communications. By reducing expectations of privacy for 73 Internet-based communication, this surveillance circumscribes the 74 conditions under which users will feel it is safe or appropriate to 75 use the network. This state surveillance thus amounts to an attack 76 on the value of the Internet, as it reduces the network effect of 77 each user's participation. This document argues that it is the 78 responsibility of the Internet engineering community to restore that 79 trust and proposes a touchstone or litmus test for protocols and 80 systems intended for Internet scale. 82 2. Motivation 84 Surveillance gives rise to self-censorship. Because the Internet is 85 one of a very few global communication technologies, the impact of 86 pervasive surveillance on it is self-censorship on a scale that harms 87 humanity as a whole. Individuals who would use the network to speak 88 may remain mute. Both within and among nations, communities which 89 would otherwise form or grow may be retarded in their emergence or 90 completely silenced. The scope of human interconnection is being 91 damaged by these actions, and it must be restored. 93 3. What is to be done? 95 The Internet must change to respond to pervasive monitoring. Where 96 protocols have traditionally mandated the implementation of integrity 97 protection and confidentiality but not mandated their use, the use of 98 techniques to achieve these must become a baseline expectation. 99 Mechanisms to detect forgery of credentials must be improved and 100 deployed. We must consider more carefully and more consistently the 101 effects of information leakage by DNS and other infrastructure. 102 Review and re-review of the components and systems which enable 103 confidentiality and integrity protection must become a norm. 105 4. A personal touchstone 107 Beyond these thoughts of the Internet infrastructure changes required 108 to restore trust in the network, I believe Internet engineers need to 109 have a focus on the users of their systems and protocols in order to 110 see the impact of the tradeoffs they are making. An example for me 111 is this: 113 "Can a gay kid in Uganda use this safely?" 115 If the answer to that is "yes", chances are it meets a reasonable set 116 of confidentiality and integrity requirements. If the answer is 117 "no", the default response for me will be to take it back to the 118 forge for a bit more fire and shaping. In extraordinary 119 circumstances, another response would be a very strong statement of 120 the limits on when this tool could be used. 122 Obviously, there are many possible litmus tests which could be 123 applied. I have chosen this one in part because Uganda has a 124 challenging network environment where it would be tempting to 125 optimize network capacity or locality in ways which risk privacy. I 126 have chosen it in part because gay people are a target of state 127 suspicion or action in multiple countries. Mostly, though, I have 128 chosen it because gay kids who find no community kill themselves in 129 shocking numbers. There can be for me no better call to action to 130 restore the human communication that this monitoring costs. 132 As noted above, this is a personal touchstone, and it may not be 133 appropriate for all readers, all circumstances, or the community 134 as whole. I believe, however, that considering the impact of 135 pervasive surveillance is difficult in part because its effects 136 are diffused across the whole network. Focusing on a touchstone 137 user or class of users can help focus consideration of the impact 138 of protocol choices or system design decisions. I encourage 139 readers making such choices to choose their own. 141 5. Security Considerations 143 This document asserts that mandatory to implement security is too 144 weak a response to pervasive surveillance, and it proposes that 145 confidentiality and integrity protection become the norm. It also 146 suggests that the balance between confidentiality and other 147 optimizations needs to be seriously reconsidered by the Internet 148 community as a whole. 150 6. IANA Considerations 152 This document makes no requests of IANA 154 7. Acknowledgments 156 The author thanks those folks kind enough to review early versions 157 of this document. 159 8. References 161 Author's Address 163 Ted Hardie 165 Email: Ted.ietf@gmail.com