search

GrumpyOldTroll / draft-jholland-quic-multicast

Work in progress to propose a multicast extension to quic.
Other
7 stars 6 forks source link

Integrity and MC_INTEGRITY #87

Open LPardue opened 2 years ago

LPardue commented 2 years ago

Section 4.3 says:

Data transmitted in a multicast channel is encrypted with symmetric keys so that on-path observers without access to these keys cannot decode the data. However, since potentially many receivers receive identical packets and identical keys for the multicast channel and some receivers might be malicious, the packets are also protected by MC_INTEGRITY (Section 10.5) frames transmitted over a separate integrity-protected path.

A client MUST NOT decode packets on a multicast channel for which it has not received a matching hash in an MC_INTEGRITY frame over a different integrity-protected communication path. The different path can be either the unicast connection or another multicast channel with packets that were verified with an earlier MC_INTEGRITY frame.

My initial comprehension was that MC_INTEGRITY frames are only delivered over the unicast channel, so they are always delivered in packets that have integrity, confidentiality and authenticity.

But this section focuses on integrity, via using the term "integrity-protected path". This makes me wonder whether there is a design intention to allow MC_INTEGRITY frames related to multicast channel A, to be delivered on multicast channel B, as long as the packet containing the MC_INTEGRITY frame has a chain of integrity back to some root (avoiding a bootstrap issue). The document doesn't really go into detail here and I think it would help to be a little clear if such a deployment is intended to be allowed.

GrumpyOldTroll commented 2 years ago

Good point, it's a relatively common point of confusion and could use clearing up.

To answer the question: yes, the design intent is to allow MC_INTEGRITY frames to be carried in a multicast channel. An MC_INTEGRITY frame carried in a channel of course requires its packet to be secured by another MC_INTEGRITY frame that contains its hash that was delivered on a secure channel such as the unicast connection, which would form a merkle tree.

Also note: @squarooticus in https://github.com/GrumpyOldTroll/draft-jholland-quic-multicast/issues/48 wants to tweak the text to permit the secure hash delivery to occur in out-of-band paths like AMBI. I'm not fully convinced that's worth including in this spec, but have deferred judgement on the point for now. And in general I agree with him that it's feasible to use an integrity anchor that comes from outside the current connection in ways that can provide adequate security--my unsureness here is about whether this is a can of worms that's worth leaving open in this doc, and whether it's likely to provoke any needlessly difficult discussions.

LPardue commented 2 years ago

The merkle tree thing is an "obvious" next step in a reasoning chain, the new text in the PR does a good job of "stating the obvious". I'm happy with that right now. I don't know enough about AMBI to have a useful opinion - maybe that's something that today's design allows to happen in the future but without needing to add complication to an MVP spec,