MC_CHANNEL_INTEGRITY frames MUST be protected against injection, modification, and repla

[squarooticus]

"Integrity" as defined in draft-krose-multicast-security is specific to multicast (and necessarily weaker than for unicast). So I think the use of "integrity" in normative language here is probably ambiguous. The key properties are protection against:

• Injection: an attacker, including other receivers, must not be able to create new channel integrity frames that will be accepted by a properly-functioning receiver.
• Modification: an attacker, including other receivers, must not be able to modify channel integrity frames such that they will be accepted by a properly-functioning receiver.
• Replay: an attacker, including other receivers, must not be able to alter the content delivered to a receiver through the replay of previously-seen channel integrity frames.

Right now, all three properties are achieved by sending (and presumably accepting) such frames only over unicast QUIC. In the future, the first two properties will be provided by something like AMBI-over-unicast-or-signed-manifest or ALTA, while the third is (now and in the future) provided by the fact that channel integrity frames are stateless and declarative (i.e., a given frame has an immutable meaning).

[squarooticus]

I should emphasize that until we have out-of-band integrity, any channel integrity packets received over multicast MUST be dropped. We could track the provenance of QUIC packets throughout the stack, or drop such privileged frames before they are injected into whatever packet queue exists in the code (if any; I don't know quite how that works yet). But I do find the way it is designed elegant in the sense that adding OOB integrity protection requires no changes to the QUIC frames as-defined here, only to how they are authenticated and interpreted.

[GrumpyOldTroll]

I don't follow. The current intent is that if an integrity frame is received in a packet delivered with a multicast channel, it is accepted only if the packet containing the frame has a hash in another integrity frame that was accepted. So they can be accepted over either unicast or multicast.

As a practical matter, I agree there has to be be a unicast anchor, but a packet with its integrity guaranteed by a prior integrity frame can contain more integrity frames, and this provides transitive integrity much like a Merkle tree, doesn't it?

[GrumpyOldTroll]

That said, +1 to making a solid definition of the properties that are provided by the integrity frames, that's a great insight. But I think the properties provided are for QUIC packets delivered over multicast channels. This provides (I think?) the same 3 properties for whatever frames are carried within those packets, right?

[squarooticus]

I don't follow. The current intent is that if an integrity frame is received in a packet delivered with a multicast channel, it is accepted only if the packet containing the frame has a hash in another integrity frame that was accepted. So they can be accepted over either unicast or multicast.

Well, it's more complicated, right? It's either a hash in another accepted integrity frame, or it's delivered over unicast (which has QUIC-native integrity guarantees). It's the principle that every integrity frame must be cryptographically linked to an established root of trust.

[squarooticus]

So, scratch my objection to multicast-delivered integrity frames. Instead: ideally, the draft would specify a necessary and sufficient set of conditions for an integrity frame to be accepted that will not require updating when AMBI or ALTA are introduced.

[GrumpyOldTroll]

I think we can close this, right? Or @squarooticus did you have some text you wanted to put in about this to try to phrase it so AMBI can be used without making it confusing?

[squarooticus]

I don't have text yet, but I would like to write some. Can we keep this open until I have a chance to look at it?

[squarooticus]

If you make me a contributor, I can assign it to myself.