idnits 2.17.1 draft-kucherawy-httpbis-dict-sec-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 5, 2018) is 1998 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 8478 (Obsoleted by RFC 8878) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual submission M. Kucherawy 3 Internet-Draft Facebook, Inc. 4 Intended status: Informational November 5, 2018 5 Expires: May 9, 2019 7 Security Considerations Regarding Compression Dictionaries 8 draft-kucherawy-httpbis-dict-sec-00 10 Abstract 12 Data compression algorithms benefit from blocks of tuning data called 13 "dictionaries". These can greatly improve data compression speed 14 and/or ratios, but their use and application has numerous potential 15 security issues of concern to the communities using them. This 16 document enumerates security issues known about compression 17 dictionaries at the time of publication so that future proposals for 18 use of dictionaries can benefit from this collected material. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 9, 2019. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Dictionary Security Concerns . . . . . . . . . . . . . . . . . 3 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 61 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 62 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5 63 Appendix B. Prior Art . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 Brotli [RFC7932] and Zstandard [RFC8478] are examples of two modern 68 data compression algorithms. While useful in their basic forms, they 69 can be made far more effective with specific types of payloads when 70 used with an object called a "dictionary". A dictionary is a map 71 that can be applied during compression or uncompression that provides 72 an advantage when operating against specific types of content. One 73 might, for example, develop a dictionary that makes the compression 74 algorithm more effective when applied to specific types of audio 75 data. 77 As dictionaries are being developed, some issues have come to light 78 that indicate ways that use of dictionaries might introduce 79 destructive side effects to the environment in which their use is 80 applied. This document is a collection of those topics, which can be 81 consulted as work on dictionaries progresses; later, as RFCs are 82 published advancing dictionaries, the content of this document could 83 be used as a checklist to ensure that either the algorithms or their 84 specification documents have been appropriately evaluated against 85 these concerns. 87 2. Definitions 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 91 "OPTIONAL" in this document are to be interpreted as described in BCP 92 14 [RFC2119] [RFC8174] when, and only when, they appear in all 93 capitals, as shown here. 95 3. Dictionary Security Concerns 97 These subsections each describe an issue that has been raised with 98 respect to use of dictionaries as input to compression and 99 uncompression. Where possible and known, acceptable mitigations are 100 described. 102 [TODO: This is a bullet list for now, but each bullet item will 103 gradually be converted into a subsection containing relevant 104 discussion.] 106 o Attacks that use dictionary-based compression to recover content 107 in the response. 109 o Attacks that use dictionary-based compression to recover content 110 in the dictionary. 112 o Attacks that leverage dictionary-based compression to violate 113 CORS/SOP/CSP. [need references and expansions for these] 115 o Attacks that manipulate a response's content by manipulating the 116 contents of a dictionary. 118 o Attacks that obfuscate a malicious response's content through the 119 use of dictionary-based compression. 121 o Attacks that identify users by fingerprinting their advertisement 122 or use of dictionaries. 124 o Attacks that reveal past user behavior or associations through the 125 negotiation and use of dictionaries. 127 o Attacks that use dictionaries to achieve denial-of-service / 128 resource exhaustion: 130 * against network resources 132 * against storage resources 134 * against computation resources 136 * against the client 138 * against the server 140 * against an intermediary 142 * against a third-party 144 o Inadvertent leakage of private information in the creation of 145 dictionaries. 147 o General security risks that follow from complexity of 148 implementation. 150 4. IANA Considerations 152 This document includes no actions for IANA. 154 [RFC Editor: Please remove this section before publication.] 156 5. Security Considerations 158 This document enumerates known security considerations about a space 159 that is under development. The list of issues discussed above may 160 not be exhaustive, but it is hopefully complete enough to ensure 161 quality work is produced as a result. 163 6. References 165 6.1. Normative References 167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 168 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 169 RFC2119, March 1997, 170 . 172 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 173 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 174 May 2017, . 176 6.2. Informative References 178 [RFC7932] Alakuijala, J. and Z. Szabadka, "Brotli Compressed Data 179 Format", RFC 7932, DOI 10.17487/RFC7932, July 2016, 180 . 182 [RFC8478] Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression 183 and the application/zstd Media Type", RFC 8478, 184 DOI 10.17487/RFC8478, October 2018, 185 . 187 Appendix A. Acknowledgements 189 The author wishes to acknowledge the following for their review and 190 constructive criticism of this update: TBD 192 Appendix B. Prior Art 194 Some prior art worth considering: 196 o draft-lee-sdch-spec, which was implemented in Chrome but then 197 withdrawn 199 o draft-vkrasnov-h2-compression-dictionaries 201 o draft-vandevenne-shared-brotli-format 203 o HTTPBIS discussion during IETF 97 205 o Brotli "fetch spec" proposal: https://fetch.spec.whatwg.org/ 206 o various HTTPBIS mailing list threads about dictionaries 208 Author's Address 210 Murray S. Kucherawy 211 Facebook, Inc. 212 1 Hacker Way 213 Menlo Park, CA 94025 214 US 216 EMail: msk@fb.com