Summary

  • Revision 01 of the MBONED multicast-security draft is an active Informational Internet-Draft, not an RFC, deployment report or browser capability claim.
  • A common decryption secret proves that a receiver can open the group stream; in a naïve symmetric authentication design, the same secret can also let that receiver forge data that peers accept.
  • Source authentication must remain asymmetric at each content unit, whether through delayed key disclosure, signatures or an authenticated manifest, and it must precede application or browser use.
  • Packet authenticity, replay/loss handling, request binding, channel permission and user-visible outcome are separate receipts with separate owners.

Group membership is not a speaking role

Multicast gains efficiency by sending substantially the same payload toward many receivers. Confidential delivery therefore tends to place the same decryption material in more than one endpoint. The MBONED draft makes the resulting authority problem explicit: a symmetric tag is producible by anyone who knows its key. In the ordinary two-party case that fact can remain contained. In a group, it can turn every eligible listener into a potential author.

This is not a claim that every group-security construction is broken. It is the reason the construction matters. A naïve design that uses one group secret both to decrypt and to validate authorship cannot tell the intended sender from an authorized receiver that is on path or can spoof the source. The tag can be cryptographically correct while the claimed provenance is false.

The first ledger must therefore record more than who received the secret. It must record what the secret authorizes. Decryption eligibility, content creation, source authentication, retransmission and administrative control are different roles. Naming them “members” hides the distinction just when an incident needs it most.

Asymmetry can come from keys or time

Public-key signatures create a familiar asymmetry: the sender retains the signing key and receivers obtain only a verification key. Yet this does not close the evidence chain. A receiver must still establish why that public key belongs to the desired source, for the relevant content and epoch. A signature made under the wrong trusted key is still the wrong source statement.

TESLA creates asymmetry differently. The sender tags data with symmetric material and reveals the verification key only after the protected data should have arrived. Receivers discard data received after scheduled disclosure. The cost is temporal: sender and receiver need adequate time synchronization, and an application must wait beyond one-way path delay before releasing authenticated data.

Per-packet signatures avoid that delayed disclosure but impose their own computation and key-distribution requirements. AMBI moves verification into an ordered manifest of packet digests delivered over an authenticated out-of-band channel. That channel becomes part of provenance. None of the mechanisms gives authority for free; each moves it into a different custody and timing contract.

Authentication must reach the packet before the parser

An object may be authenticated only after all of its packets have been assembled. That can be too late for an exposed browser or recovery system. If an injected packet enters one object, the final object check can fail only after memory, decoding and recovery work have already been spent. A repair path can then amplify one forged packet into many unicast requests against the provider.

Packet-granular authentication narrows this surface. A modified or forged packet can be rejected before application delivery. But authenticity alone does not provide order, uniqueness or completeness. Multicast over UDP has no native in-order delivery, reliability, de-duplication or replay defense. Sequence state or a stronger manifest still has to distinguish repetition, reordering and deletion.

The browser boundary is particularly strict because network bytes lead toward large parsers and rendering engines. “Decryptable” is not a safe pre-parser state. The release gate must be the successful source-authentication decision at the intended granularity, followed by sequence and request-binding checks. A fast decoder is not a substitute for an authenticated input queue.

A valid packet can answer the wrong request

HTTPS normally binds a response to the request carried through the same protected unicast exchange. Multicast is naturally unidirectional; the channel does not carry the browser's initiating request. A packet can therefore be valid for a trusted channel and still be the wrong answer for this client operation.

The draft gives a concrete failure shape: an on-path adversary might swap packets between two multicast channels that the client trusts. If source authentication covers only the channel packet, both streams can remain authentic. Without a cryptographic request binding, the application cannot prove which request induced which object.

This distinction is operationally useful. Source identity answers “who authored these bytes?” Request binding answers “which client act are these bytes answering?” Application authorization answers “may this object be used here?” The rendered result answers what actually occurred. Combining those four events in one success counter destroys the audit trail.

Encryption does not erase the receiver set

Payload encryption hides content from parties without the key. It does not make the traffic shape disappear. Packet sizes, timing, endpoints and protocol patterns can remain observable. Multicast adds a distinctive fact: an on-path observer can establish that substantially identical payloads reached multiple receivers even when it cannot decrypt them.

Membership can also be visible through IGMP or MLD at nearby network elements. An observation at one path element may show that some downstream entity joined a source-and-group channel without identifying the exact person. That limited ambiguity is not anonymity. Moving the subscription across access networks can correlate multicast membership with encrypted unicast control traffic.

The same group key enlarges compromise scope. One compromised receiver can disclose content protected by that key. Rotation and deletion bound the time window only if old keys are actually discarded and later traffic uses a new epoch. Key delivery over a forward-secret unicast channel helps protect past epochs from later long-term-key compromise; it does not retroactively narrow who held the group key during the epoch.

The browser and the network hold different circuit breakers

A hostile origin can ask a browser to join many multicast channels. The first defense is a browser rule that restricts channel association to the hosting origin or requires an explicit cross-origin authorization comparable to CORS. This is a grant to request a join, not proof that the network can safely carry every subscription.

The second defense belongs upstream. A router can observe abusive subscription patterns or overload and apply circuit breakers, including dropping unpopular content. That decision has a different authority and denominator. The browser can protect the user from an origin; the network can protect shared capacity; neither action proves content authenticity or application acceptance.

Private browsing adds another boundary. Joining a group can reveal metadata to network elements even if the payload and control channel are encrypted. The draft therefore says private mode should require explicit user approval. The approval covers a metadata-bearing join, not the truth, safety or usefulness of every packet later delivered.

Metrics must retain the missing steps

A single “secure multicast session” metric is not auditable. Better counters preserve the chain: receivers admitted to key delivery, keys delivered, current key epochs, packets decrypted, content units source-authenticated, packets rejected, replays detected, gaps observed, request bindings verified, browser-origin permissions granted, pre-render drops, objects accepted and outcomes observed.

Denominators matter. Authentication failures per packet can look small while one failed object triggers thousands of repairs. Successful decryptions per receiver can look high while request bindings fail. Short rotation intervals can look strong while retired keys remain on devices. Each ratio must state its population, epoch and authority.

Incident review should keep hypothesis separate from observation. “A receiver forged the stream” requires evidence about key custody, tag construction, source address and packet path. A valid-looking tag under a group key proves none of those causes by itself. The correct first statement is narrower: a content unit passed or failed a specified verification rule under a specified key epoch.

Sources and limits

The frozen packet contains revision 01 and its Datatracker record, history and references; the MBONED working group; the Internet and UDP threat-model RFCs; source-specific multicast and interdomain ASM deprecation; TLS 1.3; TESLA, ALC/NORM authentication and reliability sources; WebRTC browser security, Client Hints, QUIC, WebTransport and AMBI records.

They establish protocol text and official status. They do not establish implementation conformance, adoption, performance, a real forgery, receiver compromise, privacy incident or browser-rendered result. The opening is a constructed case used to test the authority chain.

Sources