



TODO Working Group                                               K. Rose
Internet-Draft                                 Akamai Technologies, Inc.
Intended status: Informational                                 M. Franke
Expires: 20 April 2026                                         TU Berlin
                                                              J. Holland
                                               Akamai Technologies, Inc.
                                                         17 October 2025


      Security and Privacy Considerations for Multicast Transports
                draft-ietf-mboned-multicast-security-00

Abstract

   Interdomain multicast has unique potential to solve delivery
   scalability for popular content, but it carries a set of security and
   privacy issues that differ from those in unicast delivery.  This
   document analyzes the security threats unique to multicast-based
   delivery for Internet and Web traffic under the Internet and Web
   threat models.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/squarooticus/draft-krose-multicast-security.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 20 April 2026.







Rose, et al.              Expires 20 April 2026                 [Page 1]

Internet-Draft        Multicast Transport Security          October 2025


Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Web Security Model  . . . . . . . . . . . . . . . . . . .   3
   2.  Threat Model  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Multicast Transport Properties  . . . . . . . . . . . . .   4
     2.2.  Authentication  . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Integrity . . . . . . . . . . . . . . . . . . . . . . . .   7
     2.4.  Confidentiality . . . . . . . . . . . . . . . . . . . . .   9
       2.4.1.  Privacy . . . . . . . . . . . . . . . . . . . . . . .   9
       2.4.2.  Personal Data . . . . . . . . . . . . . . . . . . . .  11
       2.4.3.  Forward Secrecy . . . . . . . . . . . . . . . . . . .  11
       2.4.4.  Bypassing Authentication  . . . . . . . . . . . . . .  12
     2.5.  Request/Response Binding  . . . . . . . . . . . . . . . .  13
     2.6.  Non-linkability . . . . . . . . . . . . . . . . . . . . .  13
     2.7.  Browser-Specific Threats  . . . . . . . . . . . . . . . .  13
       2.7.1.  Access to Local Resources . . . . . . . . . . . . . .  14
       2.7.2.  Injection . . . . . . . . . . . . . . . . . . . . . .  14
       2.7.3.  Hostile Origin  . . . . . . . . . . . . . . . . . . .  14
       2.7.4.  Private Browsing Modes  . . . . . . . . . . . . . . .  15
     2.8.  Other Threats . . . . . . . . . . . . . . . . . . . . . .  15
       2.8.1.  Referrer Checks . . . . . . . . . . . . . . . . . . .  15
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     5.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18







Rose, et al.              Expires 20 April 2026                 [Page 2]

Internet-Draft        Multicast Transport Security          October 2025


1.  Introduction

   This document examines the security considerations relevant to the
   use of multicast for scalable one-to-many delivery of application
   traffic over the Internet, along with special considerations for
   multicast delivery to clients constrained by the Web security model.

1.1.  Background

   This document assumes readers have a basic understanding of some
   background topics, specifically:

   *  The Internet threat model as defined in Section 3 of [RFC3552].

   *  The Security Considerations for UDP Usage Guidelines as described
      in Section 6 of [RFC8085], since application layer multicast
      traffic is generally carried over UDP.

   *  Source-specific multicast, as described in [RFC4607].  This
      document focuses on interdomain multicast, therefore any-source
      multicast is out of scope in accordance with the deprecation of
      interdomain any-source multicast in [RFC8815].

1.2.  Web Security Model

   The Web security model, while not yet documented authoritatively in a
   single reference, nevertheless strongly influences Web client
   implementations, and has generally been interpreted to require
   certain properties of underlying transports such as:

   *  Confidentiality: A passive observer must not be able to identify
      or access content through simple observation of the bits being
      delivered, up to the limits of metadata privacy (such as traffic
      analysis, peer identity, application/transport/security-layer
      protocol design constraints, etc.).

   *  Authenticity: A receiver must be able to cryptographically verify
      that the delivered content originated from the desired source.

   *  Integrity: A receiver must be able to distinguish between original
      content as sent from the desired source and content modified in
      some way (including through deletion) by an attacker.

   *  Non-linkability: A passive observer must not be able to link a
      single user across multiple devices or a single client roaming
      across multiple networks.





Rose, et al.              Expires 20 April 2026                 [Page 3]

Internet-Draft        Multicast Transport Security          October 2025


   For unicast transport, TLS [RFC8446] satisfies these requirements,
   therefore Web Transport [webtrans] proposes to require qualifying
   transport protocols to use "TLS or a semantically equivalent security
   protocol".

   For unicast communication this is sensible and meaningful (if
   imprecise) for an engineer with a grounding in security, but it is
   unclear how or whether 'semantic equivalence to TLS' can be directly
   interpreted in any meaningful way for multicast transport protocols.
   This document instead explicitly describes a security and privacy
   threat model for multicast transports in order to extend the Web
   security model to accommodate multicast delivery in a way that fits
   within the spirit of how that model is generally interpreted for
   unicast.

   Although defining the security protections necessary to make
   multicast traffic suitable for Web Transport is a key goal for this
   document, many of the security considerations described here would be
   equally necessary to consider if a higher level multicast transport
   protocol were to be made available via a different interface within
   clients constrained by the Web security model.

2.  Threat Model

   Fundamentally, multicast is simply an addressing scheme in which the
   destination address identifies more than one unique receiver; that
   said, this has implications for protocol design that differ greatly
   from those for unicast addressing.

   Given the virtually unbounded potential for attacks targeting data
   confidentiality and user privacy, we attempt to make the description
   of a multicast threat model tractable by taking the approach of
   highlighting areas in which multicast differs from unicast or poses
   novel challenges that are not addressed at a layer unconcerned with
   the addressing scheme.

2.1.  Multicast Transport Properties

   Unlike typical unicast transport protocols, multicast transports are
   naturally unidirectional.  Use cases for multicast transports
   typically involve one or a small number of senders transmitting data
   to a large number of receivers.  The sender may not know who the
   receivers are, or even how many of them there are, although a sender
   may require a pre-existing out-of-band relationship with receivers
   for the received data to be useful, such as via distribution of
   decryption keys only to authorized receivers.





Rose, et al.              Expires 20 April 2026                 [Page 4]

Internet-Draft        Multicast Transport Security          October 2025


   Applications built atop multicast IP or UDP must provide a mechanism
   for congestion control, just as those built atop unicast IP or UDP
   must.  Although multicast applications compliant with Section 4.1 of
   [RFC8085] will implement congestion control, in the context of a
   threat model it is important to note that malicious clients might
   attempt to use non-compliant subscriptions to multicast traffic as
   part of a DoS attack where possible, and that some applications might
   not be compliant with the recommendations for congestion control
   implementations.

   IP and UDP provide no native reliability mechanism, whether for
   unicast or multicast transmission.  Protocols leveraging multicast
   may add mechanisms for reliable delivery (see [RFC5740], [RFC5775],
   and [quic-http-mcast] for examples), but this may expand the attack
   surface against content providers if per-packet authenticity is not
   provided.  For example, in an application with unicast recovery for
   objects constructed out of multiple packets and which is limited to
   object-level authentication, if a packet is injected into the
   multicast stream receivers will fail to authenticate an entire
   object, necessitating unicast recovery by every receiver for the
   entire object.  Care must be taken to avoid such amplification attack
   vectors.

2.2.  Authentication

   The Web security model requires that data delivered to applications
   must be authenticated as having originated from the trusted peer.
   (In the case of server-only transport-level authentication schemes,
   such as the ubiquitous TLS server-only authentication employed
   throughout the Web, trust in the client may be strongly established
   at the application layer or weakly established as nothing more than
   precluding a man-in-the-middle.)

   In the unicast case, authentication of payloads in HTTPS is provided
   by a trusted octet stream, cryptographically resistant to tampering,
   bootstrapped via certificate validation and trust chain verification
   (either mutual or server-only, perhaps augmented with application-
   layer identity verification).

   Authentication of units of transport for trusted channels (think:
   individual packets or messages) is typically provided by a
   cryptographic authentication tag:

   *  Symmetric tags, such as symmetric message authentication codes
      (MACs) and authentication tags produced by authenticated
      encryption (AE) algorithms.  Because anyone in possession of the
      keying material may produce valid symmetric authentication tags,
      such keying material is typically known to at most two parties:



Rose, et al.              Expires 20 April 2026                 [Page 5]

Internet-Draft        Multicast Transport Security          October 2025


      one sender and one receiver.  Some algorithms employing symmetric
      authentication (such as TESLA, discussed below) relieve this
      constraint by imposing some different constraint on verification
      of tagged content.

   *  Asymmetric tags, typically signatures produced by public key
      cryptosystems.  These assume that only the sender has access to
      the signing key, but impose no constraints on dissemination of the
      signature verification key.

   In both cases:

   *  The receiving party must have a means for establishing trust in
      the keying material used to verify the authentication tag.

   *  Instead of directly authenticating the protected content, the tag
      may protect a root of trust that itself protects
      cryptographically-linked content.  Examples include:

      -  The TLS 1.3 handshake employing an authentication tag to reject
         MitM attacks against ECDH key agreement.

      -  An authentication tag of a Merkle tree root protecting the
         content represented by the entire tree.

   *  The authentication tag serves to provide integrity protection over
      the unit of content to which the tag applies, with additional
      mechanisms required to detect and/or manage duplication/replay,
      deletion/loss, and reordering within a sequence of such
      authenticated content units.

   Asymmetric verification of content delivered through multicast is
   conceptually identical to the unicast case, owing to the asymmetry of
   access to the signing key; but the symmetric case does not directly
   apply given that multiple receivers need access to the same key used
   for both signing and verification, which in a naïve implementation
   opens up the possibility of forgery by a receiver on-path or with the
   ability to spoof the source.

   Multiple mechanisms providing for reliable asymmetric authentication
   of data delivered by multicast have been proposed over the years.

   *  TESLA [RFC4082] achieves asymmetry between the sender and multiple
      receivers through timed release of symmetric keying material
      rather than through the assumed computational difficulty of
      deriving a signing key from a verification key in public key
      cryptosystems like RSA and ECDSA.  It employs computationally-
      inexpensive symmetric authentication tagging with release of the



Rose, et al.              Expires 20 April 2026                 [Page 6]

Internet-Draft        Multicast Transport Security          October 2025


      keying material to receivers only after they are assumed to have
      received the protected data, with any data received subsequent to
      scheduled key release to be discarded by the receiver.  This
      requires some degree of time synchronization between clients and
      servers and imposes latency above one-way path delay prior to
      release of authenticated data to applications.

   *  Simple per-packet asymmetric signature of packet contents based on
      out-of-band communication of the signature's public key and
      algorithm, for example as described in Section 3 of [RFC6584].

   *  Asymmetric Manifest-based Integrity (AMBI) [AMBI] relies on an
      out-of-band authenticated channel for distribution of manifests
      containing cryptographic digests of the packets in the multicast
      stream.  Authentication of this channel may, for instance, be
      provided by TLS if manifests are distributed using HTTPS from an
      origin known to the client to be closely affiliated with the
      multicast stream, such as would be the case if the manifest URL is
      delivered by the origin of the parent page hosting the media
      object.  Authenticity in this case is a prerequisite of the out-
      of-band channel that AMBI builds upon to provide authenticity for
      the multicast data channel.

   Regardless of mechanism, the primary goal of authentication in the
   multicast context is identical to that for unicast: that the content
   delivered to the application originated from the trusted source.
   Semantic equivalence to (D)TLS in this respect is therefore
   straightforwardly achieved by any number of potential mechanisms.

2.3.  Integrity

   Integrity in the Web security model for unicast is closely tied to
   the features provided by transports that enabled the Web from its
   earliest days.  TCP, the transport substrate for the original HTTP,
   provides in-order delivery, reliability via retransmission, packet
   de-duplication, and modest protection against replay and forgery by
   certain classes of adversaries.  SSL and TLS later greatly
   strengthened those protections.  Web applications universally rely on
   these integrity assumptions for even the most basic operations.  It
   is no surprise, then, that when QUIC was subsequently designed with
   HTTP as the model application, initial requirements included the
   integrity guarantees provided by TCP at the granularity of an
   individual stream.

   Multicast applications by contrast have different integrity
   assumptions owing to the multicast transport legacy.  UDP, the
   transport protocol atop which multicast applications are typically
   built, provides no native reliability, in-order delivery, de-



Rose, et al.              Expires 20 April 2026                 [Page 7]

Internet-Draft        Multicast Transport Security          October 2025


   duplication, or protection against replay or forgery.  Additionally,
   UDP by itself provides no protection against off-path spoofing or
   injection.  Multicast has therefore traditionally been used for
   applications that can deal with a modest loss of integrity through
   application-layer mitigations such as:

   *  Packet indexes to reveal duplication/replay and reordering, and to
      complicate off-path spoofing and injection

   *  Deletion coding to allow for passive recovery from loss/deletion

   *  Graceful degradation in response to loss/deletion, exemplified by
      video codecs designed to tolerate loss

   A baseline for multicast transport integrity that makes sense within
   the Web security model requires that we first define the minimally
   acceptable integrity requirements for data that may be presented to a
   user or otherwise input to the browser's trusted computing base.  We
   propose that the proper minimal standard given the variety of
   potential use cases, including many that have no need for reliable or
   in-order delivery, is to require protection against replay,
   injection, and modification and the ability to detect deletion, loss,
   or reordering.  This standard will necessarily constrain conformant
   application-layer protocol design, just as the Web security model
   adds constraints to vanilla TCP.

   Integrity in multicast, as in the unicast case, is partially provided
   by the authentication mechanism: for example, if authentication is
   provided at packet granularity, modified or forged packets will fail
   to authenticate and will thus not be delivered to the application.
   Lacking a bidirectional relationship at the transport layer, however,
   applications relying on multicast must otherwise provide for
   detection of and/or recovery from packet duplication/replay, loss/
   deletion, and reordering.  Some of these functions, too, may be
   provided by the authentication layer.  For instance:

   *  TESLA prevents replay and reveals reordering, but only across time
      intervals.  An application requiring finer-grained countermeasures
      against duplication/replay or reordering, or indeed any
      countermeasure to deletion/loss, would need to provide that via
      custom support (e.g., through the introduction of packet sequence
      numbers) or via an intermediate-layer protocol providing those
      functions.

   *  AMBI by design provides strong protection against duplication/
      replay and reveals reordering and deletion/loss of content packets
      through a strict in-order manifest of packet digests.




Rose, et al.              Expires 20 April 2026                 [Page 8]

Internet-Draft        Multicast Transport Security          October 2025


2.4.  Confidentiality

   In the unicast transport security context, confidentiality implies
   that an observer (passive or active) without pre-existing access to
   keying material must not be able to decrypt the bytes on the wire or
   identify the content being transferred, even if that adversary has
   access to the decrypted content via other means.  In practice, the
   former is trivially achieved through the use of authenticated key
   exchange and modern symmetric ciphers, but the latter is an ideal
   that is rarely possible owing to the substantial metadata in the
   clear on the public Internet: traffic analysis can make use of packet
   sizes and timing, endpoint identities, biases in application-layer
   protocol designs, side channels, and other such metadata to reveal an
   often surprising amount of information about the encrypted payload
   without needing access to any keying material.  (Conceptually, one
   could make many streams appear identical to a passive observer: video
   streams, for example, could be bucketed into a small number of
   bitrates with identical packet sizes and pacing via padding of the
   actual content.  This would increase overhead for servers and
   networks, primarily in terms of bandwidth utilization, that may be
   operationally unacceptable.)

   Multicast additionally introduces the complication that all receivers
   of a stream, even if such a stream is encrypted, receive the same
   payload (loss and duplication notwithstanding).  This introduces
   novel privacy concerns that do not apply to unicast transports.

2.4.1.  Privacy

   In contrast to (say) unicast TLS, on-path monitoring can trivially
   prove that identical content was delivered to multiple receivers,
   irrespective of payload encryption.  Furthermore, since those
   receivers all require the same keying material to decrypt the
   received payload, a compromise of any single receiver's device
   exposes decryption keys, and therefore the plaintext content, to the
   attacker.

   That having been said, however, there are factors and practices that
   help mitigate these additional risks:












Rose, et al.              Expires 20 April 2026                 [Page 9]

Internet-Draft        Multicast Transport Security          October 2025


   *  Multicast delivery is unidirectional from content provider to
      consumer and has no end-to-end unicast control channel association
      at the transport-layer, though such associations are generally
      unavoidable at the application layer (a common case likely being a
      referring web page).  Assuming application-layer unicast control
      plane traffic is properly secured, identifiable plaintext control
      messages are limited to IGMP or MLD messages intercepted by (and
      not retransmitted with user-identifying information by) a user's
      upstream router.

      Notwithstanding linkability via data or metadata from application-
      layer control flows, an on-path observer can thus only directly
      determine that some entity downstream of that path element has
      joined a particular multicast channel (in SSM [RFC4607],
      identified by the (source, group) pair of IP addresses).  Lacking
      a destination address, increasing the specificity of receiver
      identification would require an observer to obtain monitoring
      points closer to the user or to manipulate a user into revealing
      metadata out-of-band that the observer can tie to the user via
      traffic analysis or other means.

      This is a form of k-anonymity [k-anonymity] not available to
      unicast transports.  In the unicast case, an on-path observer has
      access to metadata specific to endpoint address pairs, including
      total flow size, packet count, port and protocol, which (in
      combination with other metadata) can later be tied to the user,
      site, service, and/or location assigned to each address at the
      given time.

      Widespread near-simultaneous unicast download events, such as
      those triggered by the release of a video game update or of an
      episode of a popular streaming video series, expose the identities
      of consumers of such content anywhere along the path from end
      users' devices to the origin through very elementary traffic
      analysis, unless measures are taken by the end user or content
      provider to hide the traffic, such as by mixing it with other
      traffic in a way that complicates disentangling individual flows.
      A properly-designed virtual private network (VPN) link could, for
      example, obfuscate flow-identifying information in traffic to a
      given user, at the expense of using greater bandwidth (for added
      chaff) and of loudly signaling to passive observers the presence
      of a VPN link.

   *  There is no standard mechanism in the multicast protocol ecosystem
      by which a passive observer may derive separate but related
      content or metadata from the multicast channel itself: in
      particular, if a multicast stream is encrypted using a key
      delivered out-of-band, there is no general means by which a



Rose, et al.              Expires 20 April 2026                [Page 10]

Internet-Draft        Multicast Transport Security          October 2025


      passive observer could directly derive the source location of the
      keying material.  For a passive observer to know what encrypted
      content is being delivered to a particular user whose channel
      subscriptions are known they would need to already know what
      content is available via that channel, either via traffic analysis
      such as in the case of passive observation of unicast TLS, or via
      a priori knowledge of related content that references the channel.
      A dragnet cataloging all content available through a particular
      origin is an example of the latter, but could be further mitigated
      via controlled access to index information, or via periodic
      changes in multicast source, group, or keying material, or some
      combination of the three.

2.4.2.  Personal Data

   A sender has responsibility not to expose personal information
   broadly.  This is not a consideration unique to multicast delivery:
   an irresponsible service could publish a web page with Social
   Security numbers or push its server TLS private key into the
   certificate transparency log as easily as it could multicast personal
   data to a large set of receivers.

   The Web security model partially mitigates negligence on the part of
   senders by mandating the use of secure transports: prohibiting the
   fetching of mixed content on a single page prevents a server from
   sending private data to a browser in the clear.  The main effect is
   to raise the bar closer to requiring bad faith or willful
   irresponsibility on the part of senders in revealing personal
   information.

   Multicast by its very nature is not generally suitable for transport
   of personal data: since the main value of leveraging a multicast
   transport is to deliver the same data to a large pool of receivers,
   such content must not include confidential personal information.
   Senders already have a responsibility to handle private information
   in a way that respects the privacy of users: the availability of
   multicast transports does not further complicate this responsibility.

2.4.3.  Forward Secrecy

   Forward secrecy (also called "perfect forward secrecy" or "PFS" and
   defined in [RFC4949]) is a countermeasure against attackers that
   record encrypted traffic with the intent of later decrypting it
   should the communicating parties' long-term keys be compromised.
   Forward secrecy for protocols leveraging time-limited keys to protect
   a communication session ("session keys") requires that such session
   keys be unrecoverable by an attacker that later compromises the long-
   term keys used to negotiate or deliver those session keys.



Rose, et al.              Expires 20 April 2026                [Page 11]

Internet-Draft        Multicast Transport Security          October 2025


   As noted earlier, confidential content delivered via multicast will
   necessarily imply delivery of the same keying material to multiple
   receivers, rather than negotiation of a unique key as is typical in
   the unicast case.  Presumably, such receivers will need to be
   individually authenticated and authorized by the content provider
   prior to delivery of decryption keys.  If this authorization and key
   delivery mechanism employs a forward secret unicast transport such as
   TLS 1.3, then so long as these encryption keys are ephemeral (that
   is, rotated periodically and discarded after rotation) the multicast
   payloads will also effectively be forward secret beyond the time
   interval of rotation, which we can consider to be the session
   duration.

2.4.4.  Bypassing Authentication

   Protocols should be designed to discourage implementations from
   making use of unauthenticated data.  The usual approach to enforcing
   this is to entangle decryption and authentication where possible, for
   example via use of primitives such as authenticated encryption.
   While ultimately authentication checks are independent of decryption
   (at least in classical cryptography), use of such primitives to
   minimize the number of places in which an incomplete or lazy
   implementation can avoid such checks constitutes best practice.  TLS
   1.3, for instance, mandates AE for all symmetric cryptographic
   operations: without writing one's own AE cipher implementation that
   purposely skips the authentication tag check, this leaves
   establishment of trust in the peer certificate as the only practical
   step an implementation can skip without impacting the ability to make
   use of the decrypted content.

   The situation in multicast is complicated by the need for more than
   two parties to have access to symmetric keys that would used to
   secure payloads via AE in the unicast case.  As discussed in
   Section 2.2, it is imperative for protocols to provide, and for
   receivers to leverage, some kind of asymmetry in authentication of
   each content unit prior to any use of said content to eliminate the
   ability for an attacker in possession of a shared symmetric key
   (possibly including an authorized receiver) to inject forged data
   into a stream that other receivers would then validate and deliver to
   applications.  This requirement to perform authentication checks
   throughout the lifetime of a stream that are separate from, and
   orthogonal to, content decryption adds an extra dimension of risk
   from implementation incorrectness, because such authentication
   becomes an on-going process rather than the result of a one-time
   certificate check at connection establishment.  Protocol designers
   and implementors are thus strongly encouraged to simplify or even
   black box such on-going authentication to minimize the potential for
   implementors or users to skip such checks.



Rose, et al.              Expires 20 April 2026                [Page 12]

Internet-Draft        Multicast Transport Security          October 2025


2.5.  Request/Response Binding

   In addition to requiring that application data be cryptographically
   authenticated, the Web security model also requires that each HTTP
   response must be bound to a specific HTTP request in a way that
   cannot be forged by an adversary.

   In the unicast case, binding of a response to a request in HTTPS is a
   direct consequence of the integrity guaranteed by the
   cryptographically protected transport stream to the image of the
   underlying HTTP protocol, which itself allows for no ambiguity in
   determining which request induced a particular response.

   Request/response binding in multicast requires additional protocol or
   application-layer support as multicast is naturally unidirectional
   and so does not carry request traffic.  Any multicast protocol
   carrying Web traffic must provide a means for cryptographically
   binding the data delivered over a multicast channel to a specific
   client request.  Failure to do so could, for example, allow an on-
   path adversary to swap the packets between two different multicast
   channels both trusted by the client without being detected prior to
   delivery to the application.

2.6.  Non-linkability

   Concern about pervasive monitoring of users culminated in the
   publication of [RFC7258], which states that "the IETF will work to
   mitigate the technical aspects of [pervasive monitoring]."  One area
   of particular concern is the ability for pervasive monitoring to
   track individual clients across changes in network connectivity, such
   as being able to tell when a device or connection migrates from a
   wired home network to a cell network.  This has motivated mitigations
   in subsequent protocol designs, such as those discussed in section
   9.5 of [RFC9000].  Migration of multicast channel subscriptions
   across network connections carries the potential for correlation of
   metadata between multicast channel subscriptions and unicast control
   channels, even when control channels are encrypted, so care must be
   taken to design protocols to avoid such correlations.

2.7.  Browser-Specific Threats

   The security requirements for multicast transport to a browser follow
   directly from the requirement that the browser's job is to protect
   the user.  Huang et al. [huang-w2sp] summarize the core browser
   security guarantee as follows:

      Users can safely visit arbitrary web sites and execute scripts
      provided by those sites.



Rose, et al.              Expires 20 April 2026                [Page 13]

Internet-Draft        Multicast Transport Security          October 2025


   The reader will find the full discussion of the browser threat model
   in section 3 of [RFC8826] helpful in understanding what follows.

2.7.1.  Access to Local Resources

   This document covers only unidirectional multicast from a server to
   (potentially many) clients, as well as associated control channels
   used to manage that communication and access to the content delivered
   via multicast.  As a result, local resource access can be presumed to
   be limited to that already available within web applications.  Note
   that these resources may include fingerprint information that can be
   used to identify or track individuals, such as information about the
   user agent, viewport size, display resolution, a concern covered in
   extensive detail in [RFC8942].

2.7.2.  Injection

   In the absence of any specific mitigations, network attackers have
   the ability to inject or modify packets in a multicast stream.  On-
   path injection and modification are trivial, but even off-path
   injection is feasible for many networks, such as those that implement
   no protections against source address spoofing.  Consequently, it is
   critical that a browser prevent any such injected or modified traffic
   from reaching large attack surfaces in the browser, such as the
   rendering code.

2.7.3.  Hostile Origin

   A hostile origin could serve a Web application that attempts to join
   many multicast channels, overwhelming the provider's network with
   undesired traffic.

   The first line of defense is the browser itself: the browser should
   at a minimum prevent joining of channels not associated with the
   hosting site.  In the general case, this implies the need for a CORS-
   like mechanism for cross-origin authorization of multicast channel
   sharing.

   The second line of defense is the network.  The user's upstream
   router can and should monitor the user's multicast behavior,
   implementing circuit breakers that will target unpopular content when
   overloaded or when an abusive subscription pattern is detected.









Rose, et al.              Expires 20 April 2026                [Page 14]

Internet-Draft        Multicast Transport Security          October 2025


2.7.4.  Private Browsing Modes

   Browsers that offer a private browsing mode, designed both to bypass
   access to client-side persistent state and to prevent broad classes
   of data leakage that can be leveraged by passive and active attackers
   alike, should require explicit user approval for joining a multicast
   group given the metadata exposure to network elements of IGMP and MLD
   messages.

2.8.  Other Threats

2.8.1.  Referrer Checks

   Unicast Web traffic has a weak form of protection against
   unauthorized use of content by third-party sites through referrer
   checks.  Browsers send a Referer [sic] header containing the parent
   page URL in requests for objects referenced in that page, which
   allows the server to reject requests from pages not authorized to
   refer to such content.  This is used, for example, to complicate the
   hosting of phishing sites, which could otherwise serve only the
   relatively small page HTML and direct the browser to fetch all other
   page objects from the legitimate origin.  This is not a strong
   security measure, as clients may render cached versions of such
   elements without checking freshness with the origin; but it does
   force the attacker to duplicate, modify, and host more content to
   convincingly mock the target site.

   Protocols enabling the delivery of Web traffic over multicast should
   include some mechanism providing a similar degree of protection
   against unauthorized use.  This is complicated by the inherently
   unidirectional nature of multicast traffic, which precludes any
   active role for the server in preventing data delivery to specific
   clients.  In lieu of this, protocols should be designed in a way that
   allows properly-functioning clients to unilaterally reject multicast
   data delivered for objects referenced by pages that the server has
   not authorized.

3.  Security Considerations

   This entire document is about security.

4.  IANA Considerations

   This document has no IANA actions.

5.  References

5.1.  Normative References



Rose, et al.              Expires 20 April 2026                [Page 15]

Internet-Draft        Multicast Transport Security          October 2025


   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <https://www.rfc-editor.org/rfc/rfc3552>.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
              <https://www.rfc-editor.org/rfc/rfc4607>.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
              <https://www.rfc-editor.org/rfc/rfc4949>.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <https://www.rfc-editor.org/rfc/rfc7258>.

   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
              Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
              March 2017, <https://www.rfc-editor.org/rfc/rfc8085>.

   [RFC8815]  Abrahamsson, M., Chown, T., Giuliano, L., and T. Eckert,
              "Deprecating Any-Source Multicast (ASM) for Interdomain
              Multicast", BCP 229, RFC 8815, DOI 10.17487/RFC8815,
              August 2020, <https://www.rfc-editor.org/rfc/rfc8815>.

5.2.  Informative References

   [AMBI]     Holland, J., Rose, K., and M. Franke, "Asymmetric Manifest
              Based Integrity", Work in Progress, Internet-Draft, draft-
              ietf-mboned-ambi-05, 17 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mboned-
              ambi-05>.

   [huang-w2sp]
              Huang, L.-S., Chen, E. Y., Barth, A., Rescorla, E., and C.
              Jackson, "Talking to Yourself for Fun and Profit", Web 2.0
              Security and Privacy (W2SP 2011) , May 2011,
              <https://ptolemy.berkeley.edu/projects/truststc/pubs/840/
              websocket.pdf>.

   [k-anonymity]
              Samarati, P. and L. Sweeney, "k-Anonymity: a model for
              protecting privacy", May 1998,
              <https://dataprivacylab.org/dataprivacy/projects/
              kanonymity/paper3.pdf>.





Rose, et al.              Expires 20 April 2026                [Page 16]

Internet-Draft        Multicast Transport Security          October 2025


   [quic-http-mcast]
              Pardue, L., Bradbury, R., and S. Hurst, "Hypertext
              Transfer Protocol (HTTP) over multicast QUIC", Work in
              Progress, Internet-Draft, draft-pardue-quic-http-mcast-11,
              4 July 2022, <https://datatracker.ietf.org/doc/html/draft-
              pardue-quic-http-mcast-11>.

   [RFC4082]  Perrig, A., Song, D., Canetti, R., Tygar, J. D., and B.
              Briscoe, "Timed Efficient Stream Loss-Tolerant
              Authentication (TESLA): Multicast Source Authentication
              Transform Introduction", RFC 4082, DOI 10.17487/RFC4082,
              June 2005, <https://www.rfc-editor.org/rfc/rfc4082>.

   [RFC5740]  Adamson, B., Bormann, C., Handley, M., and J. Macker,
              "NACK-Oriented Reliable Multicast (NORM) Transport
              Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009,
              <https://www.rfc-editor.org/rfc/rfc5740>.

   [RFC5775]  Luby, M., Watson, M., and L. Vicisano, "Asynchronous
              Layered Coding (ALC) Protocol Instantiation", RFC 5775,
              DOI 10.17487/RFC5775, April 2010,
              <https://www.rfc-editor.org/rfc/rfc5775>.

   [RFC6584]  Roca, V., "Simple Authentication Schemes for the
              Asynchronous Layered Coding (ALC) and NACK-Oriented
              Reliable Multicast (NORM) Protocols", RFC 6584,
              DOI 10.17487/RFC6584, April 2012,
              <https://www.rfc-editor.org/rfc/rfc6584>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8446>.

   [RFC8826]  Rescorla, E., "Security Considerations for WebRTC",
              RFC 8826, DOI 10.17487/RFC8826, January 2021,
              <https://www.rfc-editor.org/rfc/rfc8826>.

   [RFC8942]  Grigorik, I. and Y. Weiss, "HTTP Client Hints", RFC 8942,
              DOI 10.17487/RFC8942, February 2021,
              <https://www.rfc-editor.org/rfc/rfc8942>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.






Rose, et al.              Expires 20 April 2026                [Page 17]

Internet-Draft        Multicast Transport Security          October 2025


   [webtrans] Kinnear, E. and V. Vasiliev, "The WebTransport Protocol
              Framework", Work in Progress, Internet-Draft, draft-ietf-
              webtrans-overview-10, 7 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-
              webtrans-overview-10>.

Acknowledgments

   TODO acks

Authors' Addresses

   Kyle Rose
   Akamai Technologies, Inc.
   145 Broadway
   Cambridge, MA 02144,
   United States of America
   Email: krose@krose.org


   Max Franke
   TU Berlin
   Germany
   Email: mfranke@inet.tu-berlin.de


   Jake Holland
   Akamai Technologies, Inc.
   145 Broadway
   Cambridge, MA 02144,
   United States of America
   Email: jakeholland.net@gmail.com



















Rose, et al.              Expires 20 April 2026                [Page 18]
