idnits 2.17.00 (12 Aug 2021) /tmp/idnits28662/draft-rsalz-drbg-speck-wap-wep-01.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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 abstract seems to contain references ([RFC7258]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 08, 2016) is 2136 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Salz 3 Internet-Draft Akamai Technologies 4 Intended status: Best Current Practice July 08, 2016 5 Expires: January 9, 2017 7 No MTI Crypto without Public Review 8 draft-rsalz-drbg-speck-wap-wep-01 10 Abstract 12 Cryptography is becoming more important to the IETF and its 13 protocols, and more IETF protocols are using, or looking at, 14 cryptography to increase privacy on the Internet [RFC7258]. 16 This document specifies a proposed best practice for any mechanism 17 (or data format) that uses cryptography; namely, that RFCs cannot 18 specify an algorithm as mandatory-to-implement (MTI) unless that 19 algorithm has had reasonable public review. This document also 20 "sketches out" a rough definition around what such a review would 21 look like. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 9, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. Why is Cryptography Hard? . . . . . . . . . . . . . . . . . . 3 60 4. Things to avoid . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Why limit to MTI? . . . . . . . . . . . . . . . . . . . . . . 4 62 6. How to Do it Right . . . . . . . . . . . . . . . . . . . . . 5 63 6.1. Public Review . . . . . . . . . . . . . . . . . . . . . . 6 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 8.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Terminology 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119 [RFC2119]. 76 The term mandatory to implement (MTI) is used in this document to 77 describe a cryptographic algorithm that is listed as a MUST in an 78 RFC. 80 The term "snake oil" is used as a pejorative for something which 81 appears to do its job acceptably, but actually does not; see 82 https://en.wikipedia.org/wiki/Snake_oil_%28cryptography%29 . It is a 83 goal of the IETF that we never be misled into being, or mistakenly 84 taken as, snake oil salesman. 86 2. Introduction 88 Cryptography is becoming more important to the IETF and its 89 protocols, and more IETF protocols are using, or looking at, 90 cryptography to increase privacy on the Internet [RFC7258]. 92 This document specifies a proposed best practice for any protocol (or 93 data format) that uses cryptography. Namely, that such RFCs cannot 94 specify an algorithm as mandatory-to-implement (MTI) unless that 95 algorithm has had reasonable public review. This document also 96 "sketches out" a rough definition around what such a review would 97 look like. 99 3. Why is Cryptography Hard? 101 Cryptography is hard because it is not like traditional IETF protocol 102 deployments. In this classic situation, if one party implements a 103 protocol incorrectly, it usually becomes obvious as interoperability 104 suffers or completely fails. But with cryptography, one party can 105 have implementation defects, or known exploitable weaknesses, that 106 expose the entire communication stream to an attacker. Open source 107 and code reviews are not a panacea here, but using only widely- 108 accepted cryptographic mechanisms (e.g., avoiding facilities like 109 https://en.wikipedia.org/wiki/Dual_EC_DRBG ) will reduce the attack 110 surface. 112 Cryptography is hard because subtle design characteristics can have 113 disastrous consequences. For example, the US Digital Signature 114 Algorithm requires the random nonce to be protected and never re- 115 used. If those requirements are not met, the private key can be 116 leaked. 118 Cryptography is hard because adversaries design new attacks and 119 refine existing ones. Attacks get better over time; they never get 120 worse. For example, it is now de riguer to protect against CPU 121 timing attacks, even when the device is only viewable over a network. 122 A recent paper [acoustic] (XXX reference) can identify a private key 123 if your smartphone is just laid next to an innocuous charging device. 124 We understand power differential attacks, timing attacks, and perhaps 125 cache line attacks; we now have to think about RFI emissions from our 126 phone. 128 Cryptography is hard because the order of operations can matter. It 129 is not intuitively obvious to most developers, which should come 130 first among signing, compression and encryption. This issues was 131 first raised in Spring of 2001 [davis] but was only addressed in TLS 132 by [RFC7366] more than a dozen years later. 134 Getting the cryptography right is important because the Internet, and 135 therefore the work of the IETF, has become a tempting target for all 136 types of attackers, from individual "script kiddies," through 137 criminal commercial botnet and phishing ventures, up to national- 138 scale adversaries operating on behalf of their nation-state. 140 4. Things to avoid 142 "Sunlight is said to be the best of disinfectants; electric light the 143 most efficient policeman." - Louis Brandeis, _Other People's Money 144 and How Bankers Use it,_ first published as a set of articles in 145 _Harper's Weekly_ in 1914. 147 Cryptography that is developed in private, such as among an industry 148 consortium is a bad idea. Notable examples of this include: 150 o A5/1 and A5/2 for GSM-based mobile phones. 152 o WEP and WPA for WiFi access. 154 o SSLv2, while published, was developed by a private group at an 155 Internet startup. It had security flaws that had global effects 156 decades later, see https://drownattack.com/ . 158 It is hard to get good public review of patented cryptography, unless 159 there is a strongly compelling need. For example, decades ago RSA 160 was the only practial public-key mechanism available and it was 161 therefore studied pretty extensively. 163 Part of the concern about patented cryptography is that the patent- 164 holder has every incentive to provide that their system is good, 165 while the rest of the world generally has little interest in proving 166 that their commercial venture is bad. Examples of this include: 168 o Algebraic Eraser, prior to its presentation at IETF-xx, received 169 little public interest. 171 o There is not a great deal of study about NTRU. 173 Both of these items are "lattice cryptography" and that might also be 174 a reason for lack of review; the field might not have much interest 175 yet. 177 o XXX STILL MORE NEEDED 179 5. Why limit to MTI? 181 There is an argument that any new RFC not classified as "historical" 182 should not specify or recommend insufficiently-reviewed cryptography, 183 whether it MTI or not. This document limits itself to MTI for a 184 couple of reasons. 186 o Informational RFCs often document how to interoperate with other 187 systems, and this is useful. As examples of this, see the 188 Internet-Drfats on scrypt and [RFC7693]. 190 o Putting insufficiently-reviewed algorithms into an RFC can be one 191 way to spur interest in getting more reviews. This MUST NOT be 192 the primary motivation for inclusion, but it can be a useful side- 193 effect, and might lead to future "promotion" to MTI. Note that 194 waiting through draft and last-call state, then claiming "nobody 195 broke it" MUST NOT be used as the rationale; this is using the 196 IETF to host a "proof by contest." 198 o Drawing a strict boundary just around MTI is a tractable problem. 199 Drawing a similar boundary around all potential IETF uses of 200 cryptography is bound to have mistakes and errors, any one of 201 which can has the potential to make the IETF look bad, if not 202 incompetent. 204 o Requiring MTI to have public review also pressures everyone to 205 conform and raise the bar. Imagine a hypothetical national 206 security body that has a new cryptographic algorithm, Military 207 Top-secret Encryption, or MITE. If MITE is not MTI, then that 208 government might be hard-pressed to get it accepted into off-the- 209 shell offerings. If it is MTI without sufficient review, then 210 they have good reason to keep flaws in existing cryptography 211 private. To avoid both situations, the that government should 212 work to get MITE as an MTI, and would now have the burden to make 213 sure it receives sufficient analysis. 215 6. How to Do it Right 217 Cryptographic agility, [RFC7696], is probably a MUST. While it has 218 its detractors, there are no known (to the author) practical 219 considerations to evolving a deployed based to stronger crypto, while 220 still maintaining interoperability with existing entities. This 221 requires being able to make informed choices about when to use old 222 weak crypto, and when to use the "latest and greatest," and while not 223 much software, and essentially no end-users, are capable of making 224 that choice, it seems sadly the best we can do. 226 NIST is an important reference for crypto algorithms. Yes, they have 227 made mistakes (DUAL_EC_DRBG), but so has the IETF (opaque-prf) in the 228 same area. But they have run respected international contests and 229 their output receives heavy scrutiny. 231 The second consideration is to avoid temptation and premature 232 optimization. Do not adopt an algorithm just because it seems "small 233 and fast" or comes from "someone I respect." 235 6.1. Public Review 237 What constitutes sufficient public review? It is hard to say. This 238 section attempts to provide some guidelines. 240 An open competition, such as those that led to AES (XXX ref) and 241 SHA-3 (XXX ref) seem to be good, even when they come from sources 242 that are under widespread suspicion, like the US Government. These 243 efforts, like the Password Hashing Competition https://password- 244 hashing.net/ , had wide international participation and analysis by 245 many noted exports. 247 Papers presented in the various Crypto conferences (XXX need list) 248 are good. Same for various Usenix workshops. 250 Proof by contest - "Nobody's Claimed my $200 reward" - are generally 251 useless, for a number of reasons. They tend to be promoted by 252 amateur cryptographers as a way to get attention, and if someone 253 actually looks at them they are always cracked. Numerical analysis 254 is a better approach, albeit much harder work. Contests designed to 255 show the amount of "brute-force" work needed, such as the old RSA 256 factoring challenges, can be useful. But they do not show, for 257 example, if the cryptography under test is fundamentally flawed or 258 not. 260 Public review is also a natural fit for the IETF, which takes "rough 261 consensus and running code" as an axiom. Theory reduced to practice 262 is much easier, and much less of a limited academic exercise, to 263 review. 265 7. Acknowledgements 267 Thanks to Stephen Farrell for instigating this. 269 8. References 271 8.1. Normative References 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, 275 DOI 10.17487/RFC2119, March 1997, 276 . 278 8.2. Informative References 280 [acoustic] 281 Technion and Tel Aviv University, Weizmann Institute of 282 Science, and Tel Aviv University, "RSA Key Extraction via 283 Low-Bandwidth Acoustic Cryptanalysis", December 2013, 284 . 287 [davis] "Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, 288 PGP, and XML.", Usenix Proc. Usenix Tech. Conf., June 289 2001, . 292 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 293 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 294 2014, . 296 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 297 Security (TLS) and Datagram Transport Layer Security 298 (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, 299 . 301 [RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2 302 Cryptographic Hash and Message Authentication Code (MAC)", 303 RFC 7693, DOI 10.17487/RFC7693, November 2015, 304 . 306 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 307 Agility and Selecting Mandatory-to-Implement Algorithms", 308 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 309 . 311 Author's Address 313 Rich Salz 314 Akamai Technologies 316 Email: rsalz@akamai.com