idnits 2.17.00 (12 Aug 2021) /tmp/idnits55512/draft-krose-multicast-security-02.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 document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (31 January 2022) is 103 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 4949 == Outdated reference: A later version (-03) exists of draft-ietf-mboned-ambi-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TODO Working Group K. Rose 3 Internet-Draft J. Holland 4 Intended status: Standards Track Akamai Technologies, Inc. 5 Expires: 4 August 2022 31 January 2022 7 Security and Privacy Considerations for Multicast Transports 8 draft-krose-multicast-security-02 10 Abstract 12 Interdomain multicast has unique potential to solve delivery 13 scalability for popular content, but it carries a set of security and 14 privacy issues that differ from those in unicast delivery. This 15 document analyzes the security threats unique to multicast-based 16 delivery for Internet and Web traffic under the Internet and Web 17 threat models. 19 Discussion Venues 21 This note is to be removed before publishing as an RFC. 23 Discussion of this document takes place on the mailing list (), which 24 is archived at . 26 Source for this draft and an issue tracker can be found at 27 https://github.com/squarooticus/draft-krose-multicast-security. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 4 August 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Web Security Model . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 66 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Multicast Transport Properties . . . . . . . . . . . . . 5 68 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 5 69 3.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.4. Confidentiality . . . . . . . . . . . . . . . . . . . . . 9 71 3.4.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.4.2. Personal Data . . . . . . . . . . . . . . . . . . . . 11 73 3.4.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . 11 74 3.4.4. Bypassing Authentication . . . . . . . . . . . . . . 12 75 3.5. Non-linkability . . . . . . . . . . . . . . . . . . . . . 13 76 3.6. Browser-Specific Threats . . . . . . . . . . . . . . . . 13 77 3.6.1. Access to Local Resources . . . . . . . . . . . . . . 13 78 3.6.2. Injection . . . . . . . . . . . . . . . . . . . . . . 14 79 3.6.3. Hostile Origin . . . . . . . . . . . . . . . . . . . 14 80 3.6.4. Private Browsing Modes . . . . . . . . . . . . . . . 14 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 6.1. Normative References . . . . . . . . . . . . . . . . . . 14 85 6.2. Informative References . . . . . . . . . . . . . . . . . 15 86 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 89 1. Introduction 91 This document examines the security considerations relevant to the 92 use of multicast for scalable one-to-many delivery of application 93 traffic over the Internet, along with special considerations for 94 multicast delivery to clients constrained by the Web security model. 96 1.1. Background 98 This document assumes readers have a basic understanding of some 99 background topics, specifically: 101 * The Internet threat model as defined in Section 3 of [RFC3552]. 103 * The Security Considerations for UDP Usage Guidelines as described 104 in Section 6 of [RFC8085], since application layer multicast 105 traffic is generally carried over UDP. 107 * Source-specific multicast, as described in [RFC4607]. This 108 document focuses on interdomain multicast, therefore any-source 109 multicast is out of scope in accordance with the deprecation of 110 interdomain any-source multicast in [RFC8815]. 112 1.2. Web Security Model 114 The Web security model, while not yet documented authoritatively in a 115 single reference, nevertheless strongly influences Web client 116 implementations, and has generally been interpreted to require 117 certain properties of underlying transports such as: 119 * Confidentiality: A passive observer must not be able to identify 120 or access content through simple observation of the bits being 121 delivered, up to the limits of metadata privacy (such as traffic 122 analysis, peer identity, application/transport/security-layer 123 protocol design constraints, etc.). 125 * Authenticity: A receiver must be able to cryptographically verify 126 that the delivered content originated from the desired source. 128 * Integrity: A receiver must be able to distinguish between original 129 content as sent from the desired source and content modified in 130 some way (including through deletion) by an attacker. 132 * Non-linkability: A passive observer must not be able to link a 133 single user across multiple devices or a single client roaming 134 across multiple networks. 136 For unicast transport, TLS [RFC8446] satisfies these requirements, 137 therefore Web Transport [webtrans] proposes to require qualifying 138 transport protocols to use "TLS or a semantically equivalent security 139 protocol". 141 For unicast communication this is sensible and meaningful (if 142 imprecise) for an engineer with a grounding in security, but it is 143 unclear how or whether 'semantic equivalence to TLS' can be directly 144 interpreted in any meaningful way for multicast transport protocols. 145 This document instead explicitly describes a security and privacy 146 threat model for multicast transports in order to extend the Web 147 security model to accommodate multicast delivery in a way that fits 148 within the spirit of how that model is generally interpreted for 149 unicast. 151 Although defining the security protections necessary to make 152 multicast traffic suitable for Web Transport is a key goal for this 153 document, many of the security considerations described here would be 154 equally necessary to consider if a higher level multicast transport 155 protocol were to be made available via a different interface within 156 clients constrained by the Web security model. 158 2. Conventions and Definitions 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in BCP 163 14 [RFC2119] [RFC8174] when, and only when, they appear in all 164 capitals, as shown here. 166 3. Threat Model 168 Fundamentally, multicast is simply an addressing scheme in which the 169 destination address identifies more than one unique receiver; that 170 said, this has implications for protocol design that differ greatly 171 from those for unicast addressing. 173 Given the virtually unbounded potential for attacks targeting data 174 confidentiality and user privacy, we attempt to make the description 175 of a multicast threat model tractable by taking the approach of 176 highlighting areas in which multicast differs from unicast or poses 177 novel challenges that are not addressed at a layer unconcerned with 178 the addressing scheme. 180 3.1. Multicast Transport Properties 182 Unlike typical unicast transport protocols, multicast transports are 183 naturally unidirectional. Use cases for multicast transports 184 typically involve one or a small number of senders transmitting data 185 to a large number of receivers. The sender may not know who the 186 receivers are, or even how many of them there are, although a sender 187 may require a pre-existing out-of-band relationship with receivers 188 for the received data to be useful, such as via distribution of 189 decryption keys only to authorized receivers. 191 Applications built atop multicast IP or UDP must provide a mechanism 192 for congestion control, just as those built atop unicast IP or UDP 193 must. Although multicast applications compliant with Section 4.1 of 194 [RFC8085] will implement congestion control, in the context of a 195 threat model it is important to note that malicious clients might 196 attempt to use non-compliant subscriptions to multicast traffic as 197 part of a DoS attack where possible, and that some applications might 198 not be compliant with the recommendations for congestion control 199 implementations. 201 IP and UDP provide no native reliability mechanism, whether for 202 unicast or multicast transmission. Protocols leveraging multicast 203 may add mechanisms for reliable delivery (see [RFC5740], [RFC5775], 204 and [quic-http-mcast] for examples), but this may expand the attack 205 surface against content providers if per-packet authenticity is not 206 provided. For example, in an application with unicast recovery for 207 objects constructed out of multiple packets and which is limited to 208 object-level authentication, if a packet is injected into the 209 multicast stream receivers will fail to authenticate an entire 210 object, necessitating unicast recovery by every receiver for the 211 entire object. Care must be taken to avoid such amplification attack 212 vectors. 214 3.2. Authentication 216 The Web security model requires that content be authenticated 217 cryptographically. In the context of unicast transport security, 218 authentication means that content is known to have originated from 219 the trusted peer, something that is typically enforced via a 220 cryptographic authentication tag: 222 * Symmetric tags, such as symmetric message authentication codes 223 (MACs) and authentication tags produced by authenticated 224 encryption (AE) algorithms. Because anyone in possession of the 225 keying material may produce valid symmetric authentication tags, 226 such keying material is typically known to at most two parties: 227 one sender and one receiver. Some algorithms (such as TESLA, 228 discussed below) relieve this constraint by imposing some 229 different constraint on verification of tagged content. 231 * Asymmetric tags, typically signatures produced by public key 232 cryptosystems. These assume that only the sender has access to 233 the signing key, but impose no constraints on dissemination of the 234 signature verification key. 236 In both cases: 238 * The receiving party must have a means for establishing trust in 239 the keying material used to verify the authentication tag. 241 * Instead of directly authenticating the protected content, the tag 242 may protect a root of trust that itself protects 243 cryptographically-linked content. Examples include: 245 - The TLS 1.3 handshake employing an authentication tag to reject 246 MitM attacks against ECDH key agreement. 248 - An authentication tag of a Merkle tree root protecting the 249 content represented by the entire tree. 251 * The authentication tag serves to provide integrity protection over 252 the unit of content to which the tag applies, with additional 253 mechanisms required to detect and/or manage duplication/replay, 254 deletion/loss, and reordering within a sequence of such 255 authenticated content units. 257 Asymmetric verification of content delivered through multicast is 258 conceptually identical to the unicast case, owing to the asymmetry of 259 access to the signing key; but the symmetric case does not directly 260 apply given that multiple receivers need access to the same key used 261 for both signing and verification, which in a naive implementation 262 opens up the possibility of forgery by a receiver on-path or with the 263 ability to spoof the source. 265 Multiple mechanisms providing for reliable asymmetric authentication 266 of data delivered by multicast have been proposed over the years. 268 * TESLA [RFC4082] achieves asymmetry between the sender and multiple 269 receivers through timed release of symmetric keying material 270 rather than through the assumed computational difficulty of 271 deriving a signing key from a verification key in public key 272 cryptosystems like RSA and ECDSA. It employs computationally- 273 inexpensive symmetric authentication tagging with release of the 274 keying material to receivers only after they are assumed to have 275 received the protected data, with any data received subsequent to 276 scheduled key release to be discarded by the receiver. This 277 requires some degree of time synchronization between clients and 278 servers and imposes latency above one-way path delay prior to 279 release of authenticated data to applications. 281 * Simple per-packet asymmetric signature of packet contents based on 282 out-of-band communication of the signature's public key and 283 algorithm, for example as described in Section 3 of [RFC6584]. 285 * Asymmetric Manifest-based Integrity (AMBI) [AMBI] relies on an 286 out-of-band authenticated channel for distribution of manifests 287 containing cryptographic digests of the packets in the multicast 288 stream. Authentication of this channel may, for instance, be 289 provided by TLS if manifests are distributed using HTTPS from an 290 origin known to the client to be closely affiliated with the 291 multicast stream, such as would be the case if the manifest URL is 292 delivered by the origin of the parent page hosting the media 293 object. Authenticity in this case is a prerequisite of the out- 294 of-band channel that AMBI builds upon to provide authenticity for 295 the multicast data channel. 297 Regardless of mechanism, the primary goal of authentication in the 298 multicast context is identical to that for unicast: that the content 299 delivered to the application originated from the trusted source. 300 Semantic equivalence to (D)TLS in this respect is therefore 301 straightforwardly achieved by any number of potential mechanisms. 303 3.3. Integrity 305 Integrity in the Web security model for unicast is closely tied to 306 the features provided by transports that enabled the Web from its 307 earliest days. TCP, the transport substrate for the original HTTP, 308 provides in-order delivery, reliability via retransmission, packet 309 de-duplication, and modest protection against replay and forgery by 310 certain classes of adversaries. SSL and TLS later greatly 311 strengthened those protections. Web applications universally rely on 312 these integrity assumptions for even the most basic operations. It 313 is no surprise, then, that when QUIC was subsequently designed with 314 HTTP as the model application, initial requirements included the 315 integrity guarantees provided by TCP at the granularity of an 316 individual stream. 318 Multicast applications by contrast have different integrity 319 assumptions owing to the multicast transport legacy. UDP, the 320 transport protocol atop which multicast applications are typically 321 built, provides no native reliability, in-order delivery, de- 322 duplication, or protection against replay or forgery. Additionally, 323 UDP by itself provides no protection against off-path spoofing or 324 injection. Multicast has therefore traditionally been used for 325 applications that can deal with a modest loss of integrity through 326 application-layer mitigations such as: 328 * Packet indexes to reveal duplication/replay and reordering, and to 329 complicate off-path spoofing and injection 331 * Deletion coding to allow for passive recovery from loss/deletion 333 * Graceful degradation in response to loss/deletion, exemplified by 334 video codecs designed to tolerate loss 336 A baseline for multicast transport integrity that makes sense within 337 the Web security model requires that we first define the minimally 338 acceptable integrity requirements for data that may be presented to a 339 user or otherwise input to the browser's trusted computing base. We 340 propose that the proper minimal standard given the variety of 341 potential use cases, including many that have no need for reliable or 342 in-order delivery, is to require protection against replay, 343 injection, and modification and the ability to detect deletion, loss, 344 or reordering. This standard will necessarily constrain conformant 345 application-layer protocol design, just as the Web security model 346 adds constraints to vanilla TCP. 348 Integrity in multicast, as in the unicast case, is partially provided 349 by the authentication mechanism: for example, if authentication is 350 provided at packet granularity, modified or forged packets will fail 351 to authenticate and will thus not be delivered to the application. 352 Lacking a bidirectional relationship at the transport layer, however, 353 applications relying on multicast must otherwise provide for 354 detection of and/or recovery from packet duplication/replay, loss/ 355 deletion, and reordering. Some of these functions, too, may be 356 provided by the authentication layer. For instance: 358 * TESLA prevents replay and reveals reordering, but only across time 359 intervals. An application requiring finer-grained countermeasures 360 against duplication/replay or reordering, or indeed any 361 countermeasure to deletion/loss, would need to provide that via 362 custom support (e.g., through the introduction of packet sequence 363 numbers) or via an intermediate-layer protocol providing those 364 functions. 366 * AMBI by design provides strong protection against duplication/ 367 replay and reveals reordering and deletion/loss of content packets 368 through a strict in-order manifest of packet digests. 370 3.4. Confidentiality 372 In the unicast transport security context, confidentiality implies 373 that an observer (passive or active) without pre-existing access to 374 keying material must not be able to decrypt the bytes on the wire or 375 identify the content being transferred, even if that adversary has 376 access to the decrypted content via other means. In practice, the 377 former is trivially achieved through the use of authenticated key 378 exchange and modern symmetric ciphers, but the latter is an ideal 379 that is rarely possible owing to the substantial metadata in the 380 clear on the public Internet: traffic analysis can make use of packet 381 sizes and timing, endpoint identities, biases in application-layer 382 protocol designs, side channels, and other such metadata to reveal an 383 often surprising amount of information about the encrypted payload 384 without needing access to any keying material. (Conceptually, one 385 could make many streams appear identical to a passive observer: video 386 streams, for example, could be bucketed into a small number of 387 bitrates with identical packet sizes and pacing via padding of the 388 actual content. This would increase overhead for servers and 389 networks, primarily in terms of bandwidth utilization, that may be 390 operationally unacceptable.) 392 Multicast additionally introduces the complication that all receivers 393 of a stream, even if such a stream is encrypted, receive the same 394 payload (loss and duplication notwithstanding). This introduces 395 novel privacy concerns that do not apply to unicast transports. 397 3.4.1. Privacy 399 In contrast to (say) unicast TLS, on-path monitoring can trivially 400 prove that identical content was delivered to multiple receivers, 401 irrespective of payload encryption. Furthermore, since those 402 receivers all require the same keying material to decrypt the 403 received payload, a compromise of any single receiver's device 404 exposes decryption keys, and therefore the plaintext content, to the 405 attacker. 407 That having been said, however, there are factors and practices that 408 help mitigate these additional risks: 410 * Multicast delivery is unidirectional from content provider to 411 consumer and has no end-to-end unicast control channel association 412 at the transport-layer, though such associations are generally 413 unavoidable at the application layer (a common case likely being a 414 referring web page). Assuming application-layer unicast control 415 plane traffic is properly secured, identifiable plaintext control 416 messages are limited to IGMP or MLD messages intercepted by (and 417 not retransmitted with user-identifying information by) a user's 418 upstream router. 420 Notwithstanding linkability via data or metadata from application- 421 layer control flows, an on-path observer can thus only directly 422 determine that some entity downstream of that path element has 423 joined a particular multicast channel (in SSM [RFC4607], 424 identified by the (source, group) pair of IP addresses). Lacking 425 a destination address, increasing the specificity of receiver 426 identification would require an observer to obtain monitoring 427 points closer to the user or to manipulate a user into revealing 428 metadata out-of-band that the observer can tie to the user via 429 traffic analysis or other means. 431 This is a form of k-anonymity not available to unicast transports. 432 In the unicast case, an on-path observer has access to metadata 433 specific to endpoint address pairs, including total flow size, 434 packet count, port and protocol, which (in combination with other 435 metadata) can later be tied to the user, site, service, and/or 436 location assigned to each address at the given time. 438 Widespread near-simultaneous unicast download events, such as 439 those triggered by the release of a video game update or of an 440 episode of a popular streaming video series, expose the identities 441 of consumers of such content anywhere along the path from end 442 users' devices to the origin through very elementary traffic 443 analysis, unless measures are taken by the end user or content 444 provider to hide the traffic, such as by mixing it with other 445 traffic in a way that complicates disentangling individual flows. 446 A properly-designed virtual private network (VPN) link could, for 447 example, obfuscate flow-identifying information in traffic to a 448 given user, at the expense of using greater bandwidth (for added 449 chaff) and of loudly signaling to passive observers the presence 450 of a VPN link. 452 * There is no standard mechanism in the multicast protocol ecosystem 453 by which a passive observer may derive separate but related 454 content or metadata from the multicast channel itself: in 455 particular, if a multicast stream is encrypted using a key 456 delivered out-of-band, there is no general means by which a 457 passive observer could directly derive the source location of the 458 keying material. For a passive observer to know what encrypted 459 content is being delivered to a particular user whose channel 460 subscriptions are known they would need to already know what 461 content is available via that channel, either via traffic analysis 462 such as in the case of passive observation of unicast TLS, or via 463 a priori knowledge of related content that references the channel. 464 A dragnet cataloging all content available through a particular 465 origin is an example of the latter, but could be further mitigated 466 via controlled access to index information, or via periodic 467 changes in multicast source, group, or keying material, or some 468 combination of the three. 470 3.4.2. Personal Data 472 A sender has responsibility not to expose personal information 473 broadly. This is not a consideration unique to multicast delivery: 474 an irresponsible service could publish a web page with Social 475 Security numbers or push its server TLS private key into the 476 certificate transparency log as easily as it could multicast personal 477 data to a large set of receivers. 479 The Web security model partially mitigates negligence on the part of 480 senders by mandating the use of secure transports: prohibiting the 481 fetching of mixed content on a single page prevents a server from 482 sending private data to a browser in the clear. The main effect is 483 to raise the bar closer to requiring bad faith or willful 484 irresponsibility on the part of senders in revealing personal 485 information. 487 Multicast by its very nature is not generally suitable for transport 488 of personal data: since the main value of leveraging a multicast 489 transport is to deliver the same data to a large pool of receivers, 490 such content must not include confidential personal information. 491 Senders already have a responsibility to handle private information 492 in a way that respects the privacy of users: the availability of 493 multicast transports does not further complicate this responsibility. 495 3.4.3. Forward Secrecy 497 Forward secrecy (also called "perfect forward secrecy" or "PFS" and 498 defined in [RFC4949]) is a countermeasure against attackers that 499 record encrypted traffic with the intent of later decrypting it 500 should the communicating parties' long-term keys be compromised. 501 Forward secrecy for protocols leveraging time-limited keys to protect 502 a communication session ("session keys") requires that such session 503 keys be unrecoverable by an attacker that later compromises the long- 504 term keys used to negotiate or deliver those session keys. 506 As noted earlier, confidential content delivered via multicast will 507 necessarily imply delivery of the same keying material to multiple 508 receivers, rather than negotiation of a unique key as is typical in 509 the unicast case. Presumably, such receivers will need to be 510 individually authenticated and authorized by the content provider 511 prior to delivery of decryption keys. If this authorization and key 512 delivery mechanism employs a forward secret unicast transport such as 513 TLS 1.3, then so long as these encryption keys are ephemeral (that 514 is, rotated periodically and discarded after rotation) the multicast 515 payloads will also effectively be forward secret beyond the time 516 interval of rotation, which we can consider to be the session 517 duration. 519 3.4.4. Bypassing Authentication 521 Protocols should be designed to discourage implementations from 522 making use of unauthenticated data. The usual approach to enforcing 523 this is to entangle decryption and authentication where possible, for 524 example via use of primitives such as authenticated encryption. 525 While ultimately authentication checks are independent of decryption 526 (at least in classical cryptography), use of such primitives to 527 minimize the number of places in which an incomplete or lazy 528 implementation can avoid such checks constitutes best practice. TLS 529 1.3, for instance, mandates AE for all symmetric cryptographic 530 operations: without writing one's own AE cipher implementation that 531 purposely skips the authentication tag check, this leaves 532 establishment of trust in the peer certificate as the only practical 533 step an implementation can skip without impacting the ability to make 534 use of the decrypted content. 536 The situation in multicast is complicated by the need for more than 537 two parties to have access to symmetric keys that would used to 538 secure payloads via AE in the unicast case. As discussed in 539 Section 3.2, it is imperative for protocols to provide, and for 540 receivers to leverage, some kind of asymmetry in authentication of 541 each content unit prior to any use of said content to eliminate the 542 ability for an attacker in possession of a shared symmetric key 543 (possibly including an authorized receiver) to inject forged data 544 into a stream that other receivers would then validate and deliver to 545 applications. This requirement to perform authentication checks 546 throughout the lifetime of a stream that are separate from, and 547 orthogonal to, content decryption adds an extra dimension of risk 548 from implementation incorrectness, because such authentication 549 becomes an on-going process rather than the result of a one-time 550 certificate check at connection establishment. Protocol designers 551 and implementors are thus strongly encouraged to simplify or even 552 black box such on-going authentication to minimize the potential for 553 implementors or users to skip such checks. 555 3.5. Non-linkability 557 Concern about pervasive monitoring of users culminated in the 558 publication of [RFC7258], which states that "the IETF will work to 559 mitigate the technical aspects of [pervasive monitoring]." One area 560 of particular concern is the ability for pervasive monitoring to 561 track individual clients across changes in network connectivity, such 562 as being able to tell when a device or connection migrates from a 563 wired home network to a cell network. This has motivated mitigations 564 in subsequent protocol designs, such as those discussed in section 565 9.5 of [RFC9000]. Migration of multicast group subscriptions across 566 network connections carries the potential for correlation of metadata 567 between multicast group subscriptions and unicast control channels, 568 even when control channels are encrypted, so care must be taken to 569 design protocols to avoid such correlations. 571 3.6. Browser-Specific Threats 573 The security requirements for multicast transport to a browser follow 574 directly from the requirement that the browser's job is to protect 575 the user. Huang et al. [huang-w2sp] summarize the core browser 576 security guarantee as follows: 578 Users can safely visit arbitrary web sites and execute scripts 579 provided by those sites. 581 The reader will find the full discussion of the browser threat model 582 in section 3 of [RFC8826] helpful in understanding what follows. 584 3.6.1. Access to Local Resources 586 This document covers only unidirectional multicast from a server to 587 (potentially many) clients, as well as associated control channels 588 used to manage that communication and access to the content delivered 589 via multicast. As a result, local resource access can be presumed to 590 be limited to that already available within web applications. Note 591 that these resources may include fingerprint information that can be 592 used to identify or track individuals, such as information about the 593 user agent, viewport size, display resolution, a concern covered in 594 extensive detail in [RFC8942]. 596 3.6.2. Injection 598 In the absence of any specific mitigations, network attackers have 599 the ability to inject or modify packets in a multicast stream. On- 600 path injection and modification are trivial, but even off-path 601 injection is feasible for many networks, such as those that implement 602 no protections against source address spoofing. Consequently, it is 603 critical that a browser prevent any such injected or modified traffic 604 from reaching large attack surfaces in the browser, such as the 605 rendering code. 607 3.6.3. Hostile Origin 609 A hostile origin could serve a Web application that attempts to join 610 many multicast channels, overwhelming the provider's network with 611 undesired traffic. 613 The first line of defense is the browser itself: the browser should 614 at a minimum prevent joining of channels not associated with the 615 hosting site. In the general case, this implies the need for a CORS- 616 like mechanism for cross-origin authorization of multicast channel 617 sharing. 619 The second line of defense is the network. The user's upstream 620 router can and should monitor the user's multicast behavior, 621 implementing circuit breakers that will target unpopular content when 622 overloaded or when an abusive subscription pattern is detected. 624 3.6.4. Private Browsing Modes 626 Browsers that offer a private browsing mode, designed both to bypass 627 access to client-side persistent state and to prevent broad classes 628 of data leakage that can be leveraged by passive and active attackers 629 alike, should require explicit user approval for joining a multicast 630 group given the metadata exposure to network elements of IGMP and MLD 631 messages. 633 4. Security Considerations 635 This entire document is about security. 637 5. IANA Considerations 639 This document has no IANA actions. 641 6. References 643 6.1. Normative References 645 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 646 Requirement Levels", BCP 14, RFC 2119, 647 DOI 10.17487/RFC2119, March 1997, 648 . 650 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 651 Text on Security Considerations", BCP 72, RFC 3552, 652 DOI 10.17487/RFC3552, July 2003, 653 . 655 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 656 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 657 . 659 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 660 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 661 . 663 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 664 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 665 2014, . 667 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 668 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 669 March 2017, . 671 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 672 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 673 May 2017, . 675 [RFC8815] Abrahamsson, M., Chown, T., Giuliano, L., and T. Eckert, 676 "Deprecating Any-Source Multicast (ASM) for Interdomain 677 Multicast", BCP 229, RFC 8815, DOI 10.17487/RFC8815, 678 August 2020, . 680 6.2. Informative References 682 [AMBI] Holland, J. and K. Rose, "Asymmetric Manifest Based 683 Integrity", Work in Progress, Internet-Draft, draft-ietf- 684 mboned-ambi-02, 11 July 2021, 685 . 688 [huang-w2sp] 689 Huang, L-S., Chen, E.Y., Barth, A., Rescorla, E., and C. 690 Jackson, "Talking to Yourself for Fun and Profit", Web 2.0 691 Security and Privacy (W2SP 2011) , May 2011, 692 . 695 [quic-http-mcast] 696 Pardue, L., Bradbury, R., and S. Hurst, "Hypertext 697 Transfer Protocol (HTTP) over multicast QUIC", Work in 698 Progress, Internet-Draft, draft-pardue-quic-http-mcast-09, 699 13 August 2021, . 702 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J. D., and B. 703 Briscoe, "Timed Efficient Stream Loss-Tolerant 704 Authentication (TESLA): Multicast Source Authentication 705 Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, 706 June 2005, . 708 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 709 "NACK-Oriented Reliable Multicast (NORM) Transport 710 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 711 . 713 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 714 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 715 DOI 10.17487/RFC5775, April 2010, 716 . 718 [RFC6584] Roca, V., "Simple Authentication Schemes for the 719 Asynchronous Layered Coding (ALC) and NACK-Oriented 720 Reliable Multicast (NORM) Protocols", RFC 6584, 721 DOI 10.17487/RFC6584, April 2012, 722 . 724 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 725 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 726 . 728 [RFC8826] Rescorla, E., "Security Considerations for WebRTC", 729 RFC 8826, DOI 10.17487/RFC8826, January 2021, 730 . 732 [RFC8942] Grigorik, I. and Y. Weiss, "HTTP Client Hints", RFC 8942, 733 DOI 10.17487/RFC8942, February 2021, 734 . 736 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 737 Multiplexed and Secure Transport", RFC 9000, 738 DOI 10.17487/RFC9000, May 2021, 739 . 741 [webtrans] Vasiliev, V., "The WebTransport Protocol Framework", Work 742 in Progress, Internet-Draft, draft-ietf-webtrans-overview- 743 02, 28 July 2021, . 746 Acknowledgments 748 TODO acks 750 Authors' Addresses 752 Kyle Rose 753 Akamai Technologies, Inc. 754 145 Broadway 755 Cambridge, MA 02144, 756 United States of America 758 Email: krose@krose.org 760 Jake Holland 761 Akamai Technologies, Inc. 762 145 Broadway 763 Cambridge, MA 02144, 764 United States of America 766 Email: jakeholland.net@gmail.com