idnits 2.17.1 draft-arkko-farrell-arch-model-t-3552-additions-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 date (July 14, 2020) is 1382 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-arkko-farrell-arch-model-t-03 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-29 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational S. Farrell 5 Expires: January 15, 2021 Trinity College Dublin 6 July 14, 2020 8 RFC 3552 additions due to evolving Internet thread model 9 draft-arkko-farrell-arch-model-t-3552-additions-00 11 Abstract 13 Communications security has been at the center of many security 14 improvements in the Internet. The goal has been to ensure that 15 communications are protected against outside observers and attackers. 17 This memo suggests additions to the RFC 3552 threat model to cater 18 for the evolving security and privacy issues seen on the Internet 19 today. For instance, it is often also necessary to protect against 20 endpoints that are compromised, malicious, or whose interests simply 21 do not align with the interests of users. While such protection is 22 difficult, there are some measures that can be taken and we argue 23 that investigation of these issues is warranted. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 15, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. The range of potential changes in BCP 72/RFC 3552 . . . . . . 3 61 3. Simple change . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Change to add discussion of compromises . . . . . . . . . . . 5 63 5. Change to add guidance with regards to communications 64 security . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5.1. Limiting time scope of compromise . . . . . . . . . . . . 5 66 5.2. Forcing active attack . . . . . . . . . . . . . . . . . . 6 67 5.3. Traffic analysis . . . . . . . . . . . . . . . . . . . . 7 68 5.4. Containing compromise of trust points . . . . . . . . . . 7 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 8.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 9 75 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 Communications security has been at the center of many security 81 improvements in the Internet. The goal has been to ensure that 82 communications are protected against outside observers and attackers. 83 At the IETF, this approach has been formalized in BCP 72 [RFC3552], 84 which defined the Internet threat model in 2003. 86 The purpose of a threat model is to outline what threats exist in 87 order to assist the protocol designer. But RFC 3552 also ruled some 88 threats to be in scope and of primary interest, and some threats out 89 of scope [RFC3552]: 91 The Internet environment has a fairly well understood threat 92 model. In general, we assume that the end-systems engaging in a 93 protocol exchange have not themselves been compromised. 94 Protecting against an attack when one of the end-systems has been 95 compromised is extraordinarily difficult. It is, however, 96 possible to design protocols which minimize the extent of the 97 damage done under these circumstances. 99 By contrast, we assume that the attacker has nearly complete 100 control of the communications channel over which the end-systems 101 communicate. This means that the attacker can read any PDU 102 (Protocol Data Unit) on the network and undetectably remove, 103 change, or inject forged packets onto the wire. 105 However, the communications-security -only threat model may not 106 entirely match today's reality, as discussed in 107 [I-D.arkko-farrell-arch-model-t]. 109 The rest of this document tentatively suggests some changes to the 110 BCP. Section 2 discussses the range of potential changes, and 111 Section 3, Section 4, and Section 5 present the suggested alternative 112 changes, in increasing amount of detail. 114 Comments are solicited on this document. The best place for 115 discussion is on the model-t list. 116 (https://www.ietf.org/mailman/listinfo/model-t) 118 2. The range of potential changes in BCP 72/RFC 3552 120 BCP 72/RFC 3553 [RFC3552] defines an "Internet Threat Model" and 121 provides guidance on writing Security Considerations sections in 122 other RFCs. 124 [RFC3552] also provided a description of classic issues for the 125 development of communications security protocols. However, in the 126 nearly 20 years since the publication of RFC 3552, the practice of 127 protocol design has moved on to a fair extent. 129 It is important to note that BCP 72 is (or should be:-) used by all 130 IETF participants when developing protocols. Potential changes to 131 RFC 3552 therefore need to be brief - IETF participants cannot in 132 general be expected to devote huge amounts of time to developing 133 their security considerations text. Potential changes also need to 134 be easily understood as IETF participants from all backgrounds need 135 to be able to use BCP 72. 137 In this section we provide a few initial suggested changes to BCP 72 138 that will need to be further developed as part of this work. (For 139 example, it may be possible to include some of the guidelines from 140 [I-D.arkko-farrell-arch-model-t] Section 5 as those are further 141 developed.) 142 There are a range of possible updates. We could propose adding a 143 simple observation (Section 3), or additionally propose further 144 discussion about endpoint compromises and the need for system-level 145 security analysis (Section 4). 147 Another possibility would be to add more guidance covering areas of 148 concern, and recommendations of broadly-applicable techniques to use. 149 One suggestion (due to others) for such material is provided in 150 Section 5. 152 The authors of this memo believe that any updates to RFC 3552 should 153 be relatively high-level and short. Additional documents may be 154 needed to provide further detail. 156 3. Simple change 158 This is the simple addition we are suggesting. As evidenced in the 159 OAuth quote in [I-D.arkko-farrell-arch-model-t] Section 4 - it can be 160 useful to consider the effect of compromised endpoints on those that 161 are not compromised. It may therefore be interesting to consider the 162 consequences that would follow from a change to [RFC3552] that 163 recognises how the landscape has changed since 2003. 165 One initial, draft proposal for such a change could be: 167 OLD: 169 In general, we assume that the end-systems engaging in a protocol 170 exchange have not themselves been compromised. Protecting against 171 an attack when one of the end-systems has been compromised is 172 extraordinarily difficult. It is, however, possible to design 173 protocols which minimize the extent of the damage done under these 174 circumstances. 176 NEW: 178 In general, we assume that the end-system engaging in a protocol 179 exchange has not itself been compromised. Protecting against an 180 attack of a protocol implementation itself is extraordinarily 181 difficult. It is, however, possible to design protocols which 182 minimize the extent of the damage done when the other parties in a 183 protocol become compromised or do not act in the best interests 184 the end-system implementing a protocol. 186 4. Change to add discussion of compromises 188 The following new section could be added to discuss the capabilities 189 required to mount an attack: 191 NEW: 193 3.x. Other endpoint compromise 195 In this attack, the other endpoints in the protocol become 196 compromised. As a result, they can, for instance, misuse any 197 information that the end-system implementing a protocol has sent 198 to the compromised endpoint. 200 System and architecture aspects definitely also need more attention 201 from Internet technology developers and standards organizations. 202 Here is one possible addition: 204 NEW: 206 The design of any Internet technology should start from an 207 understanding of the participants in a system, their roles, and 208 the extent to which they should have access to information and 209 ability to control other participants. 211 5. Change to add guidance with regards to communications security 213 Finally, the following new text could be added to cover some of the 214 aspects that should be considered when designing a communications 215 security protocol that are not covered in detail in RFC 3552. 217 5.1. Limiting time scope of compromise 219 [RFC3552] Section 3 says: 221 The Internet environment has a fairly well understood threat 222 model. In general, we assume that the end-systems engaging in a 223 protocol exchange have not themselves been compromised. 224 Protecting against an attack when one of the end-systems has been 225 compromised is extraordinarily difficult. It is, however, 226 possible to design protocols which minimize the extent of the 227 damage done under these circumstances. 229 Although this text is technically correct, modern protocol designs 230 such as TLS 1.3 and MLS often try to provide a fair amount of defense 231 against various kinds of temporary compromise. Specifically: 233 NEW: 235 Forward Security: Many protocols are designed so that compromise 236 of an endpoint at time T does not lead to compromise of data 237 transmitted prior to some time T' < T. For instance, if a 238 protocol is based on Diffie-Hellman key establishment, then 239 compromise of the long-term keys does not lead to compromise of 240 traffic sent prior to compromise if the DH ephemerals and traffic 241 keys have been deleted. 243 Post-Compromise Security: Conversely, if an endpoint is 244 compromised at time T, it is often desirable to have the protocol 245 "self-heal" so that a purely passive adversary cannot access 246 traffic after a certain time T' > T. MLS, for instance, is 247 designed with this property. 249 Containing Partial Authentication Key Compromise: If an endpoint 250 is stolen and its authentication secret is stolen, then an 251 attacker can impersonate that endpoint. However, there a number 252 of scenarios in which an attacker can obtain use of an 253 authentication key but not the secret itself (see, for instance 254 [Jager2015]). It is often desirable to limit the impact of such 255 compromises (for instance, by avoiding unlimited delegation from 256 such keys). 258 Short-lived keys: Typical TLS certificates last for months or 259 years. There is a trend towards shorter certificate lifetimes so 260 as to minimize risk of exposure in the event of key compromise. 261 Relatedly, delegated credentials are short-lived keys the 262 certificate's owner has delegated for use in TLS. These help 263 reduce private key lifetimes without compromising or sacrificing 264 reliability. 266 5.2. Forcing active attack 268 [RFC3552] Section 3.2 notes that it is important to consider passive 269 attacks. This is still valid, but needs further elaboration: 271 NEW: 273 In general, it is much harder to mount an active attack, both in 274 terms of the capabilities required and the chance of being 275 detected. A theme in recent IETF protocols design is to build 276 systems which might have limited defense against active attackers 277 but are strong against passive attackers, thus forcing the 278 attacker to go active. 280 Examples include DTLS-SRTP and the trend towards opportunistic 281 security. However, ideally protocols are built with strong defenses 282 against active attackers. One prominent example is QUIC, which takes 283 steps to ensure that off-path connection resets are intractable in 284 practice. 286 5.3. Traffic analysis 288 [RFC3552] Section 3.2.1 describes how the absence of TLS or other 289 transport-layer encryption may lead to obvious confidentiality 290 violations against passive attackers. This too is still valid, but 291 does not take into account additional aspects: 293 NEW: 295 However, recent trends in traffic analysis indicate encryption 296 alone may be insufficient protection for some types of application 297 data [I-D.wood-pearg-website-fingerprinting]. Encrypted traffic 298 metadata, especially message size, can leak information about the 299 underlying plaintext. DNS queries and responses are particularly 300 at risk given their size distributions. Recent protocols account 301 for this leakage by supporting padding. 303 Some examples of recent work in this area include support for padding 304 either generically in the transport protocol (QUIC 305 [I-D.ietf-quic-transport] and TLS [RFC8446]), or specifically in the 306 application protocol (EDNS(0) padding option for DNS messages 307 [RFC7830]). 309 5.4. Containing compromise of trust points 311 Many protocols are designed to depend on trusted third parties (the 312 WebPKI is perhaps the canonical example); if those trust points 313 misbehave, the security of the protocol can be completely 314 compromised. 316 Some additional guidance in RFC 3552 might be needed to remind 317 protocol readers of this. 319 NEW: 321 A number of recent protocols have attempted to reduce the power of 322 trust points that the protocol or application depends on. For 323 instance, Certificate Transparency attempts to ensure that a CA 324 cannot issue valid certificates without publishing them, allowing 325 third parties to detect certain classes of misbehavior by those 326 CA. Similarly, Key Transparency attempts to ensure that (public) 327 keys associated with a given entity are publicly visible and 328 auditable in tamper-proof logs. This allows users of these keys 329 to check them for correctness. 331 In the realm of software, Reproducible Builds and Binary Transparency 332 are intended to allow a user to determine that they have received a 333 valid copy of the binary that matches the auditable source code. 334 Blockchain protocols such as Bitcoin and Ethereum also employ this 335 principle of transparency and are intended to detect misbehavior by 336 members of the network. 338 6. Security Considerations 340 The entire memo covers the security considerations. 342 7. IANA Considerations 344 There are no IANA considerations in this work. 346 8. References 348 8.1. Normative References 350 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 351 Text on Security Considerations", BCP 72, RFC 3552, 352 DOI 10.17487/RFC3552, July 2003, 353 . 355 8.2. Informative References 357 [I-D.arkko-farrell-arch-model-t] 358 Arkko, J. and S. Farrell, "Challenges and Changes in the 359 Internet Threat Model", draft-arkko-farrell-arch-model- 360 t-03 (work in progress), March 2020. 362 [I-D.ietf-quic-transport] 363 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 364 and Secure Transport", draft-ietf-quic-transport-29 (work 365 in progress), June 2020. 367 [I-D.wood-pearg-website-fingerprinting] 368 Goldberg, I., Wang, T., and C. Wood, "Network-Based 369 Website Fingerprinting", draft-wood-pearg-website- 370 fingerprinting-00 (work in progress), November 2019. 372 [Jager2015] 373 Jager, T., Schwenk, J., and J. Somorovsky, "On the 374 Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 375 v1.5 Encryption", Proceedings of ACM CCS 2015, DOI 376 10.1145/2810103.2813657, https://www.nds.rub.de/media/nds/ 377 veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf , 378 October 2015. 380 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 381 DOI 10.17487/RFC7830, May 2016, 382 . 384 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 385 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 386 . 388 Appendix A. Contributors 390 Eric Rescorla and Chris Wood provided much of the text in Section 5. 392 Appendix B. Acknowledgements 394 The authors would like to thank the IAB: 396 Alissa Cooper, Wes Hardaker, Ted Hardie, Christian Huitema, Zhenbin 397 Li, Erik Nordmark, Mark Nottingham, Melinda Shore, Jeff Tantsura, 398 Martin Thomson, Brian Trammel, Mirja Kuhlewind, and Colin Perkins. 400 The authors would also like to thank the participants of the IETF 401 SAAG meeting where this topic was discussed: 403 Harald Alvestrand, Roman Danyliw, Daniel Kahn Gilmore, Wes Hardaker, 404 Bret Jordan, Ben Kaduk, Dominique Lazanski, Eliot Lear, Lawrence 405 Lundblade, Kathleen Moriarty, Kirsty Paine, Eric Rescorla, Ali 406 Rezaki, Mohit Sethi, Ben Schwartz, Dave Thaler, Paul Turner, David 407 Waltemire, and Jeffrey Yaskin. 409 The authors would also like to thank the participants of the IAB 2019 410 DEDR workshop: 412 Tuomas Aura, Vittorio Bertola, Carsten Bormann, Stephane Bortzmeyer, 413 Alissa Cooper, Hannu Flinck, Carl Gahnberg, Phillip Hallam-Baker, Ted 414 Hardie, Paul Hoffman, Christian Huitema, Geoff Huston, Konstantinos 415 Komaitis, Mirja Kuhlewind, Dirk Kutscher, Zhenbin Li, Julien 416 Maisonneuve, John Mattson, Moritz Muller, Joerg Ott, Lucas Pardue, 417 Jim Reid, Jan-Frederik Rieckers, Mohit Sethi, Melinda Shore, Jonne 418 Soininen, Andrew Sullivan, and Brian Trammell. 420 The authors would also like to thank the participants of the November 421 2016 meeting at the IETF: 423 Carsten Bormann, Randy Bush, Tommy C, Roman Danyliw, Ted Hardie, 424 Christian Huitema, Ben Kaduk, Dirk Kutscher, Dominique Lazanski, Eric 425 Rescorla, Ali Rezaki, Mohit Sethi, Melinda Shore, Martin Thomson, and 426 Robin Wilton 427 Finally, the authors would like to thank numerous other people for 428 insightful comments and discussions in this space. 430 Authors' Addresses 432 Jari Arkko 433 Ericsson 434 Valitie 1B 435 Kauniainen 436 Finland 438 Email: jari.arkko@piuha.net 440 Stephen Farrell 441 Trinity College Dublin 442 College Green 443 Dublin 444 Ireland 446 Email: stephen.farrell@cs.tcd.ie