idnits 2.17.1 draft-ymbk-obscurity-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'Bell95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kerc83' ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Steven M. Bellovin 3 draft-ymbk-obscurity-00.txt Randy Bush 4 2002.02.28 AT&T Research 6 Security Through Obscurity Considered Dangerous 8 Copyright (C) The Internet Society (2002). All Rights Reserved. 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 0. Abstract 31 Hiding security vulnerabilities in algorithms, software, and/or 32 hardware decreases the likelihood they will be repaired and increases 33 the likelihood that they can and will be exploited by evil-doers. 34 Discouraging or outlawing discussion of weaknesses and 35 vulnerabilities is extremely dangerous and deleterious to the 36 security of computer systems, the network, and its citizens. 38 1. Open Discussion Encourages Better Security 40 The long history of cryptography and cryptoanalysis has shown time 41 and time again that open discussion and analysis of algorithms 42 exposes weaknesses not thought of by the original authors, and 43 thereby leads to better and more secure algorithms. As Kerckhoff 44 noted about cipher systems in 1883 [Kerc83], "Il faut qu'il n'exige 45 pas le secret, et qu'il puisse sans inconv'enient tomer entre les 46 mains de l'ennemi." (Roughly, "the system must not require secrecy 47 and can be stolen by the enemy without causing trouble.") 49 INTERNET-DRAFT Security Through Obscurity Dangerous 2002.02.28 51 It is also against the ethos and laws of a number of countries to 52 disallow open discussion of science and technology. 54 Within the IETF, frank discussion of the flaws of proposed and actual 55 protocols has led to improvement versions. Hence, the IETF does not 56 discourage open discussion and analysis of cryptographic or security 57 methods, and enthusiastically encourages open and frank technical 58 discussion thereof in its research, working groups, mailing lists, 59 and all other discussion venues. 61 2. Revealing Vulnerabilities is Useful 63 Revealing and discussing vulnerabilities in hardware and software 64 products allows the users to protect themselves, and encourages 65 general protection and repair strategies. 67 On the other hand, there is a well-established culture of giving the 68 manufacturer of the vulnerable product a short but reasonable early 69 warning of discovered vulnerabilities so that they have an 70 opportunity to repair them and or prepare to distribute patches or 71 work-arounds. Furthermore, it is better if developers have time to 72 test their patches; much of the current mess comes from inadequate 73 software testing. 75 The IETF supports and encourages the open but prudent discussion of 76 vulnerabilities in hardware and software in all appropriate IETF 77 venues. 79 3. The Culture of Sharing 81 In parts of the hacker subculture, information is currency. That is, 82 by disclosing vulnerabilities or by providing exploit code, the 83 purveyor gains status. As a consequence, knowledge of security holes 84 tends to spread rapidly. 86 By contrast, when security professionals withhold such information 87 from the community, the broader community does not have an 88 opportunity to find solutions. In extreme cases, such as that 89 described in [Bell95], the result can be that the bad guys know about 90 the problem long before most defenders do. That, in turn, likely 91 delayed the development of cryptographic security mechanisms for the 92 DNS [RFC2065]. 94 INTERNET-DRAFT Security Through Obscurity Dangerous 2002.02.28 96 3. Security Considerations 98 This document is about security, and specifically warns about 99 increased vulnerability if weakness in algorithms and products are 100 not able to be openly discussed. 102 4. Acknowledgments 104 I dunno 106 5. References 108 [Bell95] 109 S..M. Bellovin, "Using the Domain Name System for System Break- 110 Ins", Proc. Fifth Usenix Security Symposium, 1995. 112 [Kerc83] 113 A. Kerckhoffs. "La Cryptographie Militaire". 1883. 114 116 [RFC2065] 117 D. Eastlake and C. Kaufman. "Domain Name System Security Exten- 118 sions". RFC 2065, 1997. 120 6. Authors' Addresses 122 Steven M Bellovin 123 AT&T Labs Research 124 Shannon Laboratory 125 180 Park Avenue 126 Florham Park, NJ 07932 127 Phone: +1 973-360-8656 128 email: bellovin@acm.org 130 Randy Bush 131 5147 Crystal Springs 132 Bainbridge Island, WA US-98110 133 +1 206 780 0431 134 randy@psg.com 136 INTERNET-DRAFT Security Through Obscurity Dangerous 2002.02.28 138 7. Full Copyright Statement 140 Copyright (C) The Internet Society (2001). All Rights Reserved. 142 This document and translations of it may be copied and furnished to 143 others, and derivative works that comment on or otherwise explain it 144 or assist in its implementation may be prepared, copied, published 145 and distributed, in whole or in part, without restriction of any 146 kind, provided that the above copyright notice and this paragraph 147 are included on all such copies and derivative works. However, this 148 document itself may not be modified in any way, such as by removing 149 the copyright notice or references to the Internet Society or other 150 Internet organizations, except as needed for the purpose of develop- 151 ing Internet standards in which case the procedures for copyrights 152 defined in the Internet Standards process must be followed, or as 153 required to translate it into languages other than English. 155 The limited permissions granted above are perpetual and will not be 156 revoked by the Internet Society or its successors or assigns. 158 This document and the information contained herein is provided on an 159 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 160 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 161 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 162 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 163 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.