Signed Digest Manifests for Multicast Datagram Authentication

4.1. Hash Algorithms

hash_alg is a Suite ID of the IANA Named Information Hash Algorithm Registry ([RFC6920] Section 9.4), a value from 0 to 63; values 64 to 255 are not Suite IDs and MUST NOT be sent. Only a suite whose output is 256 bits is usable, since every digest field is 32 octets; the truncated suites MUST NOT be used. Suite 1, sha-256 [FIPS180-4], is mandatory to implement. A receiver MAY implement other 256-bit suites; it drops a record whose hash_alg it does not implement (Section 7). All records of one flow carry the same hash_alg for the life of a flow generation (streamId, Section 8.1); a change of algorithm is a new generation.¶

5.1. Signature Context Binding

The signature is computed over:¶

signed_message =
    "mcast-manifest-v2" || 0x00     # 18-octet prefix
 || u32(streamId)
 || S                               # 4 or 16 octets
 || G                               # 4 or 16 octets
 || u16(manifestPort)
 || record[0 .. len - 64)

with S, G, streamId and manifestPort as declared for the flow (Section 4, Section 8.1), and the signature is the 64-octet Ed25519 signature of [RFC8032] Section 5.1 (the PureEdDSA variant, with no prehash and an empty context) under the key that kid names. The prefix binds the flow's network identity; a receiver needs no state to check it beyond those four values, which it takes from the flow's metadata or its provisioning (Section 7).¶

ctx is 32 octets that a profile of this format MAY derive from the application context it binds the flow to, under a label of the profile's choosing and with the record's hash_alg ([MOQ-MULTICAST] Section 7.2.4 binds the MoQ catalog this way). A flow with no such profile sets ctx to 32 zero octets. A receiver that holds the context source recomputes ctx and MUST reject a record whose ctx differs (Section 7); any other receiver carries ctx blind. ctx is part of the signed message, not an Ed25519 context string, which the variant above does not carry.¶

A valid (record, datagrams) pair therefore cannot be replayed onto another flow, flow generation, key or epoch; sent bounds replay within an epoch to the clock tolerance of Section 7.¶

5.2. Keys, Epochs and Sequence Numbers

kid is an unsigned 32-bit integer carried in the clear in every record and names a key of the flow's key set (Section 8.1), each key signing the epochs from its firstEpoch up to, but not including, the next larger firstEpoch in the set. epoch never decreases under one kid: a sending entity MUST NOT reuse an epoch under a kid, across generations or restarts, and a generation that would start below the kid's last epoch starts under a new kid (Section 8.1).¶

The protected unit is a flow: every datagram the sender emits to one flow (S, G, port) that its metadata declares protected (Section 8.1). A flow has one manifestPort, which no other flow of the same (S, G) shares (Section 8.1); its sequence counter (below) and its mseq counter (Section 5) are kept per (kid, epoch). mseq starts at any value and increases by one for every window the flow closes under one (kid, epoch), in emission order, which the replay floor of Section 7 (mseq + 64 <= highest_mseq) and the twin deadline of Section 6 (before the signed record of window mseq + 64) assume.¶

sequence is a 64-bit counter the sender assigns per (flow, kid, epoch): it starts at any value and increases by one for every datagram the flow emits, in emission order, repair symbols included. It is carried only in manifest records, never in data datagrams, and is unrelated to any sequence number the payload carries. Digest i of a record covers sequence = first_seq + i, so one window is a contiguous run of the flow. A datagram the sender emits twice (a carousel) has two sequences and two digests. An application MUST NOT assume that sequence continues across an epoch change. Neither counter wraps within an epoch: a sender ends the epoch (the record whose flags bit 0 is set, Section 5) before either would exceed 2^64 - 1, and the comparisons this document states on them, mseq + 64 <= highest_mseq included, are integer comparisons that an implementation evaluates without unsigned underflow or overflow.¶

7.1. Source Check

On an ASM flow a receiver MUST discard, before any parsing or hashing, a datagram on port or manifestPort whose IP source address is not senderAddress; behind an AMT relay the address is that of the encapsulated header of the AMT Multicast Data message [RFC7450]. On an SSM flow reached natively the network enforces the source and a receiver SHOULD still discard a datagram whose source address is not S; a receiver reached through an AMT gateway MUST discard it, since nothing upstream of its gateway filters the encapsulated source address and [RFC7450] does not authenticate Multicast Data messages. A datagram that passes belongs to the flow (S, G, port) or (S, G, manifestPort) with S as in Section 4.¶

7.2. State

State per flow: the current epoch with the kid that set it; the grace period that ends maxAuthDelayMs + 2 x manifestTimerMs after the current epoch became current and, until it ends, the previous epoch; the flow's hash_alg, fixed by its first verified record; per (kid, epoch) the verified mseq values above the replay floor, each with the hash_alg digest of the record's bytes, the highest_mseq that verified records have raised (step 1) and, once a verified record has flags bit 0 set, the mseq that closed it; the verification budget of step 1 with a count of the records it dropped; a pending table of (digest, sequence, expiry) entries; the digests recorded as admitted, each until the time of recording plus maxAuthDelayMs; and a hold queue of (digest, datagram, expiry) entries in arrival order, digest being absent from an entry until the first record of the flow is verified (step 2). State per receiver, shared by its flows: the time of the last metadata re-fetch that an unknown kid triggered (Section 7.4), and the per-kid epoch floor kept with a key pin.¶

maxBitrate, maxAuthDelayMs and manifestTimerMs size the hold queue and the pending table (steps 1 and 2); a receiver bounds both by local policy. At the budget of step 1 the pending table holds at most 37 x (64 + 1000 x (maxAuthDelayMs + 2 x manifestTimerMs) / 1000) entries, 11,248 at the defaults, and the hold queue at most maxAuthDelayMs x maxBitrate / 8000 octets, 1.25 MB at 50 Mbit/s and the default maxAuthDelayMs.¶

7.3. Processing

A receiver applies the following, in this order, with no variable-length interpretation before a cryptographic check:¶

1. Record datagram (on manifestPort, magic "MHM2"). Require 164 <= len <= 1316 and (len - 132) mod 32 == 0. Read the fixed-offset integers magic, kid, epoch, mseq, count, hash_alg and sent and the 32 octets of ctx. Drop before any cryptography if: magic differs; kid is not in the key set, or epoch is outside its range (Section 8.1); (kid, epoch, mseq) is already verified (this drops the second copy of a record with one lookup and one hash, a copy of the previous epoch arriving after its grace period included; a dropped copy whose bytes hash, under the flow's hash_alg, to the digest kept with the verified entry is the record itself, its twin or a replay of it, and one whose bytes do not match is not; on the single record path of this document neither moves any floor or timer, highest_mseq having been raised when the entry was verified, below, and the distinction serves only a profile that adds a path (Section 7.6)); epoch is below the current epoch and is not the previous epoch within its grace period (below), or, when no record has yet been verified, is below minEpoch or below the pinned floor for its kid; mseq + 64 <= highest_mseq(kid, epoch) (replay floor, none before a record of that (kid, epoch) has raised highest_mseq, no upper bound; the sum does not wrap, Section 5.2); mseq is above the mseq that closed the epoch, once a verified record has closed it; sent is more than 7 s + maxAuthDelayMs behind, or more than 6 s ahead of, the receiver's UTC clock (freshness: the sender's 1 s bound and the receiver's 5 s bound, plus, behind, the truncation of sent to whole seconds and the delivery of the twin); count != (len - 132) / 32; hash_alg is not in the receiver's accepted set, or differs from the flow's hash_alg once one is fixed; or, on a receiver that holds the context source of Section 5.1, ctx differs from the value recomputed from it (any other receiver carries ctx blind). Charge the per-flow verification budget, a token bucket of depth 64 refilled at 1000 tokens per second; drop and count a record that finds it empty (nothing before the signature tells a forged record from a genuine one, so a forged record spends the same token, Section 10.2). Verify the Ed25519 signature over signed_message; drop on failure, and only on success read first_seq, flags and the digests. If epoch is above the current epoch, or this is the first verified record, make epoch current and make the former current epoch the previous epoch, with a grace period that ends maxAuthDelayMs + 2 x manifestTimerMs after now (the sender emitting every twin of it before the new epoch's first record, Section 6), fix the flow's hash_alg from this record if none is fixed yet, and hash every held datagram that has no digest yet; pending entries and held datagrams of the previous epoch are not flushed and live out their expiry. A record of the previous epoch that passes the checks above is processed under that epoch's own floor and verified set and never changes the current epoch. Record (kid, epoch, mseq) as verified, with the hash_alg digest of its bytes, and raise highest_mseq. For each (digest, sequence) of the record, in order: if the hold queue holds a datagram with that digest, admit the oldest such datagram, remove it from the queue and record its digest as admitted until now + maxAuthDelayMs (step 2); otherwise insert the pair into the pending table with expiry now + maxAuthDelayMs + 2 x manifestTimerMs (240 ms at the defaults). Once every pair of the record is processed, drop from the hold queue each datagram still held whose digest is now recorded as admitted: it is a repeated copy of a datagram this record admitted, which step 2 would not have held after the admission; its drop is not an expiry and counts toward nothing (Section 10.2). A window's digests are inserted once: a record for a window already verified is dropped above, so no entry is refreshed or re-inserted. If flags bit 0 is set the epoch is closed at this mseq (Section 5): later records with this epoch and a higher mseq are dropped, pending entries live out their expiry, and the next epoch is accepted by the rule above.¶

2. Data datagram (on port). Compute D with the flow's hash_alg (a datagram that arrives before the first record of the flow is verified is held without a digest) and look it up in the pending table, which maps a digest to an ordered list of sequences (carousels repeat byte-identical datagrams). Hit: remove the lowest sequence, admit the datagram and record D as admitted until now + maxAuthDelayMs. Miss: drop the datagram if D is so recorded (a copy of an admitted datagram delivered again is never held); otherwise append (D, datagram) to the hold queue with expiry now + maxAuthDelayMs, the queue bounded to maxAuthDelayMs x maxBitrate / 8000 octets; drop the newest on overflow, since dropping the oldest would let an injector purge legitimately held datagrams, and drop at expiry, as unauthenticated. Repair symbols follow the same rule, so an injected symbol is dropped before it reaches a decoder. A receiver MUST NOT deliver to an application, or feed to a decoder, a datagram of a protected flow that it has not admitted under step 1 or 2, on whatever carrier it arrived.¶

Replay. Receivers in an explicitly configured digital video recorder (DVR) or replay mode MAY relax the epoch, floor and freshness checks. A (digest, sequence) entry is consumed when matched, so a replayed datagram finds no entry unless a legitimate identical copy is still pending, in which case the replay consumes that copy and the later legitimate copy is dropped (the application receives the same bytes either way; this is a denial of service only, bounded by the carousel repeat count). Cross-flow replay is excluded by streamId, S and G in both the digest and the signature, port in the digest and manifestPort in the signature.¶

7.4. Key Rotation and Re-fetch

A key change is an epoch change (Section 5). The sender adds the next kid to the metadata with the firstEpoch at which it will sign, at least one metadata lifetime ahead; signs with it from that epoch; and raises minEpoch. A receiver that holds that metadata accepts the retired kid below the successor's firstEpoch only, so records the retired key signs are admitted until the grace period for the new epoch ends (step 1 of Section 7.3); a receiver that verifies no record of the new epoch keeps the epoch before it current, which the retired key still signs, and a receiver whose metadata or pin predates the rotation is exposed to the retired key until it re-fetches or is re-provisioned (Section 10.2). A record with an unknown kid triggers at most one metadata re-fetch per 30 s per receiver; until then such records are dropped. Whenever a re-fetch or a re-provisioning changes the key set or a kid's range, the receiver re-applies the range check of Section 8.1 to the (kid, epoch) that set each flow's current epoch; where it now fails, the receiver discards that flow's state as it does on a streamId change (Section 7.5), the digest of every held datagram included, and returns to the join state of step 1, so a record a retired key signed before the re-fetch cannot hold the flow afterwards. Revocation is key removal, effective within one metadata lifetime. The metadata lifetime is the lifetime that Section 8.3 derives from the response's Cache-Control for a receiver that uses the well-known document, and whatever bounds the validity of a DORMS record, a catalog or a provisioning otherwise.¶

7.5. Generation Change

The per-flow state of Section 7.2 belongs to the flow generation (Section 5): when the streamId the metadata, or a receiver's provisioning, declares for the flow changes, the receiver discards every per-flow item of Section 7.2 but the verification budget and its count and the hold queue (the current and previous epoch, hash_alg, the per-(kid, epoch) mseq state, the pending table and the admitted digests), clears the digest of every held datagram, and processes the next record as the first of the flow under the join-time floors of step 1 of Section 7.3.¶

7.6. Additional Record Paths

This document delivers records on manifestPort only, so the record that makes an epoch current is the first record of that epoch the receiver verifies, the grace period of the previous epoch starts at that moment, and one replay floor per (kid, epoch) suffices. A profile that adds a second record path (a unicast mirror of the same record octets, for instance) MUST specify, per path, the replay floor and the grace period a record arriving on that path meets, which records raise or start them, and a deadline after which no record of the previous epoch is admitted on any path, reckoned from the time the current epoch became current, since on such a profile a path can see the new epoch's records late or not at all; it MUST also specify which verification budget of step 1 a record arriving on each path charges, with the count of dropped records that goes with it, how a record verified on one path is treated when its copy arrives on the other, and by how much the pending-entry expiry and the admitted-digest retention of step 1 are widened for a record on that path, so that the lead of one path over the other does not expire an entry before the datagrams it covers arrive. [MOQ-MULTICAST] Section 7.2.7 does so for a MoQ manifest track: one budget per path, each with its count; the previous-epoch deadline at the bound of its Section 7.2.5 plus maxAuthDelayMs + 2 x manifestTimerMs after the current epoch became current; and the pending expiry and the admitted-digest retention widened by the mirror's lead, the bound of that section until one is measured. A profile that adds no path applies this document as written.¶

7.7. Clocks

The freshness check needs a receiver clock synchronized to UTC within 5 s. A receiver without one MAY skip that check alone; it then accepts any window of the current epoch at join and has no protection against replay of the epoch's earlier windows until its first verified record sets the floor (Section 10.2). Every other timer of this section (maxAuthDelayMs, manifestTimerMs and the expiries derived from them) is a local interval and needs no synchronized clock.¶

7.8. Cost

A datagram from another source costs one address comparison; one that spoofs S costs one hash, two lookups and, on a miss of both, space in the hold queue until expiry, so a copy of an admitted datagram costs one hash and two lookups; an injected record costs at most one verification inside the budget, a replayed one whose (kid, epoch, mseq) is still verified one lookup and one hash while its mseq is above the replay floor (the already-verified lookup of step 1 precedes the freshness check), one outside the verified set and outside the freshness tolerance that lookup alone, a miss, before the epoch floor, the replay floor or the freshness check drops it, the second copy of a verified record one lookup and one hash. With one verification per 37 datagrams, a Cortex-A53 without SHA2 instructions spends about 0.26 of a core at 100 Mbit/s and, under a record flood at a budget of 1000/s, about 0.43 of a core on signature checks, the hashing of the flow's own datagrams continuing beside them; a core with SHA2 instructions spends a fraction of that.¶

8.1. Flow Parameters

A receiver needs the following for each protected flow. They are delivered by any authenticated means a profile specifies: the well-known document of Section 8.2, a DORMS record [I-D.ietf-mboned-dorms] or AMBI metadata [I-D.ietf-mboned-ambi], an application catalog ([MOQ-MULTICAST] Section 7.2.6), or out-of-band provisioning (Section 7). The names below are those of the well-known document; a profile that carries them under other names maps them one to one.¶

• scheme (REQUIRED): the name of the scheme the flow uses, manifest-ed25519-2 for this format and ed25519-trailer-1 for Section 9, from Section 11.2.¶
• S (REQUIRED): the address from which the sending entity transmits the flow, S of Section 4. On an SSM flow it is the SSM source; on an ASM flow it is declared as senderAddress, which MUST NOT appear on an SSM flow. Two ASM flows whose senderAddress differ MAY share G and ports; the source check of Section 7 separates them.¶
• G (REQUIRED): the group address, of the same address family as S. Wherever a receiver matches metadata to a flow it compares S and G as IP addresses, never as strings, and an address of one family never matches one of the other, an IPv4-mapped IPv6 address being of the IPv6 family (Section 8.2).¶
• port (REQUIRED): the UDP destination port of the data datagrams, and the source port from which the sender emits every datagram of the flow (Section 4).¶
• manifestPort (integer, REQUIRED): destination port of the record datagrams, twins included, on the flow's (S, G); MUST differ from the port of every flow of the same (S, G) the metadata declares, this flow included, and from the manifestPort of every other such flow, so that no port of an (S, G) carries both data and records, or the records of two flows. A receiver MUST NOT join a protected flow whose ports violate this. Metadata MUST declare each (S, G, port) at most once; a receiver whose metadata declares one twice holds no parameters for that flow and does not join it (Section 8.2).¶
• streamId (integer, REQUIRED): 32-bit value chosen per flow generation, bound into every digest and signature.¶
• keys (array, REQUIRED): one to four {kid, publicKey, firstEpoch} objects. kid is an unsigned 32-bit integer carried in the clear in every record; publicKey is the 32-octet Ed25519 public key; firstEpoch is the first epoch the key signs. A key signs the epochs from its firstEpoch up to, but not including, the next larger firstEpoch in the array, and the key with the largest firstEpoch signs every later epoch. kid values MUST be unique within the key set and firstEpoch values MUST be distinct within the array. A receiver that takes its keys from metadata whose key set repeats a kid or a firstEpoch, or names a publicKey that is not 32 octets, holds no key set for the flow or flows that key set is attached to (below): it admits nothing from them, as it does on a flow whose records carry an algorithm it does not implement (Section 7), and the other flows of the same metadata, with key sets of their own, are unaffected; a receiver that pins keys is unaffected, since its key set comes from the pin. A receiver drops, before verification, a record whose epoch is outside its kid's range (Section 7), so a retired key cannot carry a receiver past its successor's firstEpoch.¶
• minEpoch (integer, REQUIRED): the lowest epoch a receiver accepts at join (step 1 of Section 7.3); after its first verified record the current epoch is the floor, with the previous epoch admitted until its grace period ends, maxAuthDelayMs + 2 x manifestTimerMs after the current epoch became current (step 1). The sender MUST write the current epoch at every epoch change, sender restart included, so a joiner with current metadata cannot be fed an earlier epoch.¶
• maxAuthDelayMs (integer, OPTIONAL, default 200, range 50 to 1000): how long a receiver holds a datagram whose digest has not arrived.¶
• manifestTimerMs (integer, OPTIONAL, default 20, at least 1): the window timer of Section 6.¶
• maxBitrate (integer, REQUIRED): the sender's declared ceiling for the flow in bit/s, which bounds the receiver's hold queue (step 2 of Section 7.3). [MOQ-MULTICAST] declares the same value as the endpoint's bandwidth.¶

The ranges above are binding. A receiver that finds maxAuthDelayMs outside 50 to 1000 or manifestTimerMs below 1 MUST either clamp it to the nearest bound or decline the flow, as its profile specifies, and MUST NOT use the out-of-range value. The other parameters are identifiers or sizes, not tunables, and a clamped identifier names a port, key, generation or epoch the sender never declared: a receiver that finds a keys array of no or more than four entries, a port or manifestPort of 0, a maxBitrate that is not a positive integer, or port, manifestPort, streamId, kid, firstEpoch or minEpoch outside its field width, MUST decline the flow. The browser profile clamps maxAuthDelayMs (to 50 and 1000).¶

maxAuthDelayMs, manifestTimerMs and maxBitrate are per flow. keys and minEpoch are per key set; the metadata attaches a key set to one flow (the well-known document carries one per channel, Section 8.2) or to several ([MOQ-MULTICAST] Section 7.2.6 carries one per broadcast), and every flow it is attached to uses that key set and that minEpoch. A flow using ed25519-trailer-1 declares scheme, S, G, port, keys and maxBitrate only.¶

8.2. The Well-Known Document

A sender that serves receivers which can fetch over HTTPS publishes its flows' parameters at¶

https://<S>/.well-known/multicast-receive

where <S> is the SSM source address as the IP address literal in the host of an https URI ([RFC9110] Section 4.3.5), IPv6 in brackets, never a host name; the well-known URI is registered in Section 11.1. The document is JSON [RFC8259], served with the media type application/json; the well-known URI is used with the https URI scheme only:¶

{
  "version": 1,
  "channels": [
    {
      "source": "198.51.100.7",
      "group": "232.10.20.30",
      "port": 5004,
      "maxBitrate": 8000000,
      "integrity": {
        "scheme": "manifest-ed25519-2",
        "manifestPort": 5005,
        "streamId": 2864434397,
        "minEpoch": 17,
        "maxAuthDelayMs": 200,
        "manifestTimerMs": 20,
        "keys": [
          {
            "kid": 1,
            "publicKey":
              "A6EHv_POEL4dcN0Y50vAmWfk1jCbpQ1fHdyGZBJVMbg",
            "firstEpoch": 1
          }
        ]
      }
    }
  ]
}

version (integer, REQUIRED): the document format; this document defines 1. A document whose version is not 1 is not used: a receiver treats it as listing no channel (Section 8.3) and takes no parameter from it, so no flow is protected on its account. A receiver ignores a member it does not recognize at the document, channel, integrity and key level, so that a later revision of this document can add members under version 1 without disturbing a receiver that implements this one; version changes only when a receiver that implements this document would otherwise misread the new format.¶

channels (array, REQUIRED): one object per flow the source serves to such receivers. A document that is not a JSON object, or whose channels is not an array, lists no channel. Each carries source (S, an IP literal, equal to the address the document was fetched from), group (G), port, maxBitrate and an integrity object with scheme and, for manifest-ed25519-2, manifestPort, streamId, minEpoch, maxAuthDelayMs, manifestTimerMs and keys, each as Section 8.1 defines it; publicKey is base64url-encoded without padding ([RFC4648] Section 5), 43 characters for the 32 octets. For ed25519-trailer-1 the integrity object carries scheme and keys only. A receiver matches a flow by (S, G, port) exactly, comparing source and group to S and G as IP addresses after parsing their textual forms, not as strings, since an IPv6 literal has several textual forms; source and group MUST be IP address literals in the IPv4address or IPv6address form of [RFC3986] Section 3.2.2 (dotted-decimal with no leading zeros; IPv6 without brackets or a zone identifier), never names, of one address family, that of the address the document was fetched from, and a receiver ignores a channel whose address members are not; an IPv4-mapped IPv6 literal is of the IPv6 family and does not match an IPv4 address, the families themselves having to match. It ignores an element of channels that is not a JSON object, a channel it cannot match, every channel whose (S, G, port) another channel of the same document also declares, one whose ports violate Section 8.1, one that lacks a member this section or Section 8.1 marks REQUIRED for its scheme, or carries a member of this section under a JSON value of a kind other than the one named here (a number with an integer value for port, kid, firstEpoch and each member this section or Section 8.1 calls an integer, a string for source, group, scheme and publicKey, an object for integrity and for each element of keys, an array for keys), a member of the wrong kind being absent, so that a REQUIRED one leaves the channel ignored and an OPTIONAL one takes its default, one whose keys array yields no key set (no or more than four entries, a repeated kid or firstEpoch, or a publicKey that is not 43 base64url characters decoding to 32 octets, Section 8.1), and one whose scheme it does not implement; each of these is ignored alone, and the other channels of the document are unaffected. The document describes SSM flows only, since it is fetched from S; an ASM flow's metadata is delivered by other means. A receiver bounds the size of the document and the number of channels by local policy.¶

8.3. Fetching the Document

A receiver fetches the document with an HTTPS GET addressed to the IP literal S. The server's certificate MUST contain an iPAddress subjectAltName ([RFC5280] Section 4.2.1.6) carrying S in native width in network byte order, an IP-ID in the terms of [RFC9525] Section 1.5, and the receiver MUST verify the certificate as an https client does for a host that is an IP literal ([RFC9110] Section 4.3.4), with S as its IP-ID reference identifier and an octet-for-octet match of S against that entry, no partial match ([RFC9525] Sections 6.2 and 6.4); no DNS record is a security boundary of this format, and a receiver never resolves a name to find the document. A receiver MUST NOT follow a redirect, and it sends no credentials.¶

A receiver that acts on behalf of a web origin sends that origin in the Origin request header, as the CORS protocol of [WHATWG-FETCH] does, and the response MUST carry an Access-Control-Allow-Origin header naming that origin; a wildcard is not consent, nor is a response that carries no Access-Control-Allow-Origin header or one naming another origin or the string null, which names no origin, and such a receiver MUST treat each of them as listing no channel for its origin and MUST NOT use it for that origin. A receiver acting for an origin that serializes to null sends no Origin header and treats the response as listing no channel for it, and a sender MUST NOT send Access-Control-Allow-Origin: null. A sender that publishes for every origin echoes the request's Origin, a null Origin excepted, which it answers as it answers a request that carries no Origin header, and sends Vary: Origin, as [WHATWG-FETCH] asks of any response whose Access-Control-Allow-Origin is not a single static value, so that a cache, the receiver's own or one shared on the path to S, does not serve one origin's response, or the response to a request that carried no Origin header, to another origin. This is the per-origin gate that [I-D.ietf-mboned-dorms] Sections 2.3.5 and 4.5 place on DORMS metadata, carried from a DNS-discovered server to the source address itself and with the wildcard rejected rather than discouraged; it is the CORS-like cross-origin authorization that [I-D.ietf-mboned-multicast-security] Section 2.7.3 asks for. A receiver that acts for no origin sends no Origin header and ignores the response header.¶

A receiver keeps the parameters it took from the document for a metadata lifetime (Section 7.4) derived from the response's Cache-Control and clamped to 60 s at least and 24 h at most: the value of the max-age directive ([RFC9111] Section 5.2.2.1) less the response's current age, reckoned as Section 4.2.3 of that document does from the Age and Date header fields and the receiver's own request and response times; Expires, s-maxage and heuristic freshness (its Sections 5.3, 5.2.2.10 and 4.2.2) are not consulted. A response with no Cache-Control, with no max-age or a max-age that is not a non-negative integer, or one that carries no-store or no-cache (its Sections 5.2.2.5 and 5.2.2.4), gives the minimum, 60 s. This lifetime governs the parameters the receiver holds, not the HTTP response: any HTTP cache the receiver's fetch passes through follows [RFC9111] as usual, so a no-store response is not stored and a no-cache one is not reused without validation. The receiver re-fetches the document when that lifetime expires; such a re-fetch that fails, or returns a response the receiver cannot use (one that does not verify as this section requires, is not the document of Section 8.2, carries a version the receiver does not implement, or carries no consent for its origin, as above), is treated as a document that lists no channel for the flow, since a receiver that kept the expired document would let an attacker that can block the fetch keep a withdrawn grant or a removed key in force past its lifetime; a flow whose channel, key set or origin grant the re-fetched document no longer lists is left (a key set that still names a key but drops the current kid is a key-set change under Section 7.4, not a withdrawal), so withdrawal of consent is effective within one metadata lifetime, and a sender that wants faster withdrawal publishes a short lifetime or stops signing. A record with an unknown kid triggers at most one re-fetch per 30 s per receiver (Section 7.4); a re-fetch so triggered that fails, or returns a response the receiver cannot use, leaves the parameters the receiver holds in force until their lifetime expires, since the records that triggered it are unauthenticated and are dropped either way, and treating that failure as a withdrawal would let any host that can inject one such record and keep the server's answer from the receiver make every receiver that holds the metadata leave the flow at once.¶

10.1. Properties Provided

For a flow using manifest-ed25519-2, a receiver that follows Section 7 delivers no datagram that the sender did not emit on that flow, under that key, in that epoch and flow generation (integrity and origin authenticity per datagram); admits each (digest, sequence) pair at most once and verifies each record once (replay, bounded within an epoch by sent at join and by the replay floor after the first verified record); and can detect deletion, loss and reordering within an epoch of the flow, since digest i of a record covers sequence = first_seq + i and the sequences of admitted datagrams are known. sequence and mseq restart at any value at an epoch change (Section 5.2, Section 5), so where an epoch began is not known to a receiver, and where it ended is known only from a verified record whose flags bit 0 is set (Section 7.3); a deletion at either boundary is not a gap. That is the minimal standard of [I-D.ietf-mboned-multicast-security] Section 2.3, "protection against replay, injection, and modification and the ability to detect deletion, loss, or reordering", a deleted datagram being a gap in the admitted sequences as a lost one is, and no mode of this document delivers an unauthenticated datagram (Section 2.4.4 of that document). Because every datagram, repair symbols included, is admitted by its own digest before any use, an injected datagram cannot invalidate an object or a repair block and so force recovery, the amplification that Section 2.1 of that document describes; because a receiver delivers nothing it has not admitted, injected or modified traffic reaches no parser, decoder or renderer behind it, as Section 2.7.2 requires; and because a receiver can reject a flow its metadata does not authorize for the origin on whose behalf it acts (Section 8.3), it can unilaterally reject data the sender has not authorized for that page, the property Section 2.8.1 asks for. The pseudoheader in every digest and the prefix in every signature bind the datagrams to the flow and its generation, so an on-path adversary cannot swap the datagrams of two flows a receiver trusts, the example Section 2.5 of that document gives of what unbound delivery permits; that section asks for binding to a specific client request, and this document binds data to the flow the receiver chose to join and, where a profile derives ctx, to its application context, which is as far as a format with no return channel binds it.¶

The format provides no confidentiality: datagrams, records and keys are visible to every receiver and to the path, and the digests reveal whether two datagrams are identical. It provides no protection of availability (Section 10.2).¶

The format rests on the second-preimage resistance of H: an attacker that can find, for a digest in a verified record, another pseudoheader || payload with that digest has it admitted in place of the sender's datagram (Section 4); where the attacker can influence what the sender transmits it rests on collision resistance as well, and so does a profile that derives ctx with H (Section 5.1). A datagram whose content an attacker can predict lets it run that second-preimage search before the sender transmits the datagram, the offline attack on predictable packets that [I-D.ietf-mboned-ambi] Section 8.1 describes; the pseudoheader adds nothing unpredictable, so the format relies on the strength of H alone against it rather than on unpredictable content. Collision difficulty is the digest anchor that Section 2.1 of [I-D.ietf-mboned-ambi] names, and SHA-256 provides both properties at the full 256-bit output that Section 4.1 requires. The Named Information Hash Algorithm Registry carries a Status field ([RFC6920] Section 9.4); a suite the registry marks deprecated no longer offers that assurance, and a sender that moves to another suite starts a new flow generation (Section 4.1). No receiver holds a secret: the verification keys are public, so a compromised or malicious receiver can forge nothing that another receiver admits, the asymmetric authentication of each content unit before any use that Section 2.4.4 of [I-D.ietf-mboned-multicast-security] asks for; for a receiver that pins keys, the signing key is the flow's only long-term secret (Section 10.3).¶

10.2. Threat Model

This format protects against off-path and on-segment UDP injection, against corrupted or attacker-injected repair symbols, and against replay: a (record, datagrams) pair cannot be moved to another flow, flow generation, key or epoch (Section 5.1); an earlier epoch is rejected at join by minEpoch (Section 8.1) and, on a receiver that pins keys, by the epoch floor kept with the pin, and after the first verified record by the current epoch, the previous epoch admitted until its grace period ends (Section 7); and within an epoch a receiver with a UTC-synchronized clock admits no window whose record was emitted more than 7 s + maxAuthDelayMs before receipt, so the verification budget cannot be spent with stale genuine records and the replay floor of Section 7 takes over after the first verified record. A receiver that skips the freshness check can be fed the current epoch's earlier windows at join, and an injector that keeps its budget spent can hold it there. Clock skew beyond the 1 s and 5 s bounds of Section 5 and Section 7.7 costs availability where it makes the receiver's clock fast or the sender's slow: genuine records are dropped as stale. Skew the other way, a receiver clock slow or a sender clock fast by X in total, widens the replay window: the receiver admits at join windows older than the tolerance states by X, within the bounds as beyond them, and once X passes about 6 s it drops genuine records as future and admits only what an injector replays from that far back, so a receiver that cannot keep its clock within its bound does better to skip the freshness check, as Section 7.7 allows, than to check against a clock it does not trust. An injector that can only replay what the multicast path has already delivered meets the already-verified lookup and the replay floor of step 1.¶

Metadata rewrite and key substitution are defended only for receivers that hold an out-of-band key pin. The digest algorithm is inside the signed record, so a rewrite can declare the flow unprotected, substitute keys or lower minEpoch; the pin catches the first two and the per-kid epoch floor kept with it (Section 7) the third, except where a lowered minEpoch admits records of an earlier epoch signed with a still-listed kid: every earlier epoch at a receiver's first join under that kid, and at any later join the highest epoch verified under it, which the floor keeps rather than drops, so a holder of a still-listed retired key signs fresh records of that epoch; either is admitted until a record of the current epoch is verified, and after that as the previous epoch (step 1 of Section 7.3), so rotated-out keys SHOULD be removed promptly. A rewrite that raises minEpoch costs a receiver, pinned or not, that session's data and nothing more, since neither carries a metadata value past the session (Section 7). Rewriting any other parameter of the flow only makes genuine records fail the signature or ctx check, or resizes the hold queue and pending expiry (maxBitrate, maxAuthDelayMs, manifestTimerMs), which a receiver bounds by local policy (Section 7.2). A rewrite that redirects a receiver to another (S, G) is a join the receiver's metadata source authorized, and what it then receives verifies under the keys that metadata names or not at all; bounding the joins a receiver performs on behalf of one metadata source is a matter for the profile.¶

This format protects integrity, not availability. A forged record passes every check of step 1 of Section 7.3 up to the signature, so each one spends a token of the verification budget: an attacker who sustains more than 1000 records per second on the manifest port (about 1.3 Mbit/s of 164-octet records) takes a share of the budget proportional to its rate, and at several times that rate both copies of a window lose their tokens and the flow yields no data. The budget bounds the receiver's CPU; it does not raise the cost of this attack, and the record flood is not the cheapest availability attack on every protected flow: a datagram on the data port that matches no pending entry is held until it expires (step 2 of Section 7.3), and those expiries are loss to the application, so an injector that sustains, with the same access as the record flood, a given loss fraction does so for less than the 1000 records per second the record flood needs wherever that fraction of the flow's packet rate is below it, as on every audio flow and most low-rate video; only evicting genuine datagrams, by overflowing the hold queue, needs the flow's bandwidth. On an SSM flow reached natively either flood must spoof S or be on path; on an ASM flow any host that can send to the group suffices, and so it does behind an AMT gateway, where a flood need only spoof the relay's address toward the gateway (Section 7). A datagram that expires from the hold queue is loss to the application; a held copy that step 1 drops because a record admitted another copy of the same datagram is not. A receiver SHOULD report records that the budget dropped for want of a token as loss as well, so that a sustained record flood is visible to the application rather than ending in silence.¶

Joining (S, G) delivers to the receiver's host every datagram the network forwards for (S, G), on every port, before any verification: multicast routing selects on addresses, not on UDP ports. Section 8.2 of [I-D.ietf-mboned-ambi] describes what that does outside the receiver, a datagram injected into a subscribed group reaching an unrelated application on the host that listens on the unspecified address at another port, and recommends that senders list every flow they send in their metadata and that a firewall block multicast traffic to the unsecured ports of an (S, G) that carries secured traffic; a receiver that implements this document is not that application, but it pays for every datagram on port and manifestPort as Section 7.8 states, so an attacker that can inject into the group spends the receiver's link before any check, and, where it sends as S (or as senderAddress on an ASM flow, Section 7.1), its hashing budget as well; a datagram from any other source costs the one comparison of Section 7.8. This document bounds the price per datagram and the state: a datagram on port that passes the source check costs one hash and space in the hold queue, which is bounded in octets, until it expires, when it is dropped as unauthenticated, loss the application sees (step 2 of Section 7.3); one on manifestPort costs at most one verification inside the budget of step 1. The link capacity the injected traffic takes and the rate at which the receiver keeps hashing it are bounded by nothing here: a ceiling on the datagrams a receiver accepts from a joined group, counted before verification, and what it does when the ceiling is exceeded, belong to the profile's ingress ceiling (the browser profile leaves the group).¶

A receiver that holds the metadata naming the successor key accepts the retired kid only below the successor's firstEpoch (Section 8.1), and records of the previous epoch only within its grace period, so for that receiver a key retired at an epoch boundary signs records admitted for at most maxAuthDelayMs + 2 x manifestTimerMs after the new epoch's first record is verified. An attacker that drops every record of the new epoch keeps the epoch before the change current at that receiver, and, holding the retired key, signs records that receiver admits until a record of the new epoch reaches it, the metadata removes the retired kid or the receiver is re-provisioned, minEpoch binding only a join. A receiver with older metadata is exposed to the retired key until it re-fetches, one metadata lifetime plus the 30 s re-fetch interval of Section 7.4 at most, and a pinned receiver until it is re-provisioned.¶

Losing both copies of a window leaves at most 37 datagrams unauthenticated, which expire from the hold queue. Latency of authentication is bounded by maxAuthDelayMs. Digest i of a record covers sequence = first_seq + i, so deletion, loss and reordering within an epoch of a flow are detectable (the "ability to detect deletion, loss, or reordering" that [I-D.ietf-mboned-multicast-security] Section 2.3 requires), and no mode of this document delivers an unauthenticated datagram (Section 2.4.4 of that document). A lost signed record is covered by its twin, at most maxAuthDelayMs / 2 later, so a held datagram waits at most that plus the burst that removed the record. The replay floor of 64 records below highest_mseq tolerates reordering of records on the manifest port by up to 63 windows, which is also the bound Section 6 places on the twin's lag; a record reordered further is dropped, and its window is lost unless its other copy arrived in time.¶

A receiver that pins keys is exposed to nothing the metadata source can do beyond that session's data and the state that Section 7.2 bounds by local policy: a minEpoch raise, a streamId change or a changed port, manifestPort or context source makes genuine records fail, maxBitrate, maxAuthDelayMs and manifestTimerMs resize its hold queue and pending table, and a changed (S, G) is a join its metadata source authorized, but none of them lets it admit a datagram the sender did not emit; a receiver that does not pin is exposed to the metadata source as to the sender, which is why a profile fixes how the metadata is authenticated (Section 8.1, Section 8.3).¶

The hold queue and its consume-on-admission rule descend from AMBI ([I-D.ietf-mboned-ambi] Section 3.2): a (digest, sequence) entry is consumed by one admission, and a copy of an admitted datagram that arrives while its digest is recorded as admitted, for maxAuthDelayMs after the admission, is dropped rather than held (steps 1 and 2 of Section 7.3). The hold-down of that section, which keeps a consumed digest from being re-learned for the same sequence number from a later manifest, is replaced by the rule that a window's digests are inserted once, by the first verified copy of the record that carries them, its twin being dropped as already verified (step 1). The hold times are cut from the default hold times its Section 3.2.1 recommends, 2 s for data packets and 10 s for packet digests, to maxAuthDelayMs for datagrams (200 ms at the default) and maxAuthDelayMs + 2 x manifestTimerMs for digests (240 ms at the defaults).¶

10.3. Sender Responsibilities

For a receiver that pins keys, the signing key is the flow's only long-term secret: a sender that loses it to an attacker has given that attacker the flow until the key is removed from the metadata and every receiver has re-fetched or been re-provisioned, so a sender SHOULD keep a successor key published ahead of need (Section 7.4) and remove a retired key promptly. The key that replaces a compromised one MUST carry a kid that no earlier key of the key set has carried: a receiver that pins keys keeps across sessions the highest epoch it has verified under each pinned kid (Section 7), an attacker holding the key can have raised that floor under the old kid past every epoch the sender will use (the newest key's range has no upper bound, Section 8.1), and a replacement under the same kid would be dropped at join by every such receiver. For a receiver that takes its keys from the well-known document there is a second one, the private key of the TLS certificate for S, or whatever else authenticates the metadata channel a profile uses: its compromise lets an attacker publish keys of its own to every such receiver (Section 10.5), so the sender guards it as it guards the signing key. A sender MUST NOT reuse an epoch under a kid (Section 5.2), which requires it to keep the last epoch used under each kid across restarts, or to start under a new kid after a restart whose state is lost; an epoch reused under a kid reopens the windows of its first use to replay at a receiver that joins during the reuse: every one of them at a receiver that skips the freshness check of Section 7.7, and those emitted within the tolerance of step 1 of Section 7.3 at one that checks it. A sender whose clock is off by more than the tolerance of Section 7 makes its flow unverifiable to receivers that check freshness (Section 5).¶

10.4. The Trailer Scheme

ed25519-trailer-1 costs a receiver one signature verification per datagram, so every injected datagram that passes the replay window costs a verification: on a flow where any host can send to the group, or where S can be spoofed, the receiver's CPU is the attacker's to spend, which is why a receiver MAY refuse the scheme above 10 Mbit/s and why it is not mandatory (Section 9). A receiver MAY also bound the verifications it performs per second on such a flow by local policy, the limit on authentication checks per time unit that [RFC6584] Section 7.1 recommends once the datagrams failing the check exceed a threshold, dropping genuine datagrams while the bound binds; the manifest scheme needs no such bound beyond the budget of step 1 of Section 7.3, since one verification admits up to 37 datagrams. The scheme's signed message binds S, G, port, epoch and seq but not streamId, and carries no domain-separation prefix: a datagram cannot be moved to another flow, epoch or position, and the scheme has no generation in the sense of Section 2, since a flow using it declares no streamId (Section 8.1); a sender restart is marked by epoch alone (Section 5.2). What keeps a datagram emitted before a restart out of the flow after it is epoch and seq in the signed message: the receiver drops a datagram of an epoch below the current one and one whose seq is below the window or already seen within it, and Section 5.2 forbids a sender to reuse an epoch under a kid across restarts, so a replayed datagram of an earlier epoch is admitted only at join, or on the return to the join state of Section 9, before a datagram of a later epoch has verified (below); a sender that reused an epoch under a kid across restarts would let the earlier datagrams verify at the positions the window has not yet seen and, with a seq above the right edge, move the window past the genuine datagrams that follow, which the receiver then drops. A key used under any other scheme or protocol is not separated from that use. That is a known limitation of the scheme as Section 9 defines it, which the author may change in a later revision of this document. The scheme carries no emission time and its metadata no minEpoch, so at join a receiver is exposed to replay of an earlier epoch under a still-listed key until it verifies a datagram of a later epoch, and to replay of the current epoch's earlier datagrams, each verifying as genuine, until a later datagram of that epoch verifies and moves the window's right edge past them, after which a replay 1024 or more below that edge, or already seen inside the window, is dropped (Section 9); removing retired keys promptly bounds the first exposure to the current key's epochs.¶

10.5. Trust in the Well-Known Document

The document is authenticated by the TLS certificate of the host at S, and nothing else: a certificate for S issued to an attacker, or a compromise of the host, lets the attacker substitute keys for every receiver that does not pin them, which Section 10.2 covers. A receiver that verifies the certificate against the IP literal presents no server name in the handshake, so a host that serves several names must present the certificate for S to a client that sends none ([RFC9525] Section 7.4). The per-origin grant restricts which pages may join a flow, not who may fetch the document, which is public; a sender that does not want a flow's keys and parameters public does not publish them there. The fetch is itself a unicast connection to S, repeated every metadata lifetime, that gives the operator of S the receiver's address, the time of each request and, from the Origin header, the page the receiver acts for, and lets an on-path observer infer the subscription from traffic to a known S; this is the disclosure that [I-D.ietf-mboned-dorms] Section 5.2 describes for a DORMS fetch, moved from the DORMS server to the source itself. A receiver that must not disclose this is provisioned out of band instead, or reaches S through a proxy that aggregates many receivers and does not terminate TLS, so that the certificate check against S still holds; this document specifies neither. The document directs a receiver to join (S, G); a receiver that acts for a page bounds the joins it performs for that page, since a page could otherwise direct it at many groups and exhaust the network's join state, the attack that [I-D.ietf-mboned-dorms] Section 4.5 describes.¶

11.1. Well-Known URI Registration

IANA is requested to register the following in the "Well-Known URIs" registry, following the template of [RFC8615] Section 3.1:¶

• URI suffix: multicast-receive¶
• Change controller: IETF¶
• Specification document(s): this document, Section 8.2.¶
• Status: permanent¶
• Related information: none.¶

Pending publication, the author will request a provisional registration of the same URI suffix through the registry's own procedure ([RFC8615] Section 3.1, under the Specification Required policy of its Section 5.1), with this Internet-Draft as its specification document and the author as change controller, "provisional" being the status its Section 3.1 gives a value not defined by a Standards Track RFC or other open standard; the permanent entry above replaces that provisional entry on publication.¶

11.2. Multicast Datagram Integrity Schemes Registry

IANA is requested to create a "Multicast Datagram Integrity Schemes" registry. Entries are assigned under the Specification Required policy of [RFC8126] Section 4.6. Each entry has a Value (an integer from 0 to 255), a Name (the string a flow's metadata carries as scheme, Section 8.1), a Reference and a Note. The initial contents are:¶

Value 4 is reserved for a TESLA profile ([RFC4082], [RFC5776]) and is not to be assigned until such a profile exists with an implementation on a receive-only receiver and an authenticated bound on the receiver's clock, which TESLA requires and this document does not.¶

A Name is a string of 1 to 64 characters, each a lowercase ASCII letter, a digit or a hyphen, beginning with a letter; a receiver compares it to the scheme string of a flow's metadata octet for octet, with no case folding. A Note is a short description the registrant supplies, or "reserved" or "unassigned" for an entry that has no Name. The designated expert checks that the specification defines the scheme completely enough for independent interoperable implementations, namely its wire format, its key, epoch and replay rules, and which of the parameters of Section 8.1 its metadata carries; that a receiver using the scheme admits no datagram before authenticating it (Section 7); and that the Name is not already assigned and is not confusable with an assigned Name.¶

11.3. Hash Algorithm Identifiers

This document creates no registry of hash algorithms. hash_alg values are Suite IDs of the Named Information Hash Algorithm Registry ([RFC6920] Section 9.4), which this document does not change; a new 256-bit suite is registered there under that registry's own policy.¶