search

GrumpyOldTroll / draft-jholland-quic-multicast

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

Delivery of MC_SESSION_PROPERTIES over multicast #2

Closed MaxF12 closed 2 years ago

MaxF12 commented 2 years ago

Section 9.1:

An MC_SESSION_PROPERTIES frame (type=TBD-01) is sent from server to client, either with the unicast connection or in an existing joined multicast session.

Is there any reason that this couldn't always be delivered just over the unicast stream? As the AEAD key and algorithm are mutable, I think this might expose an unnecessary attack vector. By only having it on the unicast stream its safer for both the server (as it knows all recipients that will get it) as well as the client (as it knows it comes from the legitimate source).

GrumpyOldTroll commented 2 years ago

I don't think it costs much to send this always over unicast, but I'm also not sure it buys you anything on security. My thought here was that you've exposed updates only to those who already had access to the stream.

I guess in the forward secrecy case if the shared key was leaked from a confederate, they'd have to maintain a unicast listener to get the next update. So maybe it's worth a little bit on security. It's a fair point I guess. I'm a little 'meh', the tradeoff seems relatively minor in both directions. My plan was to leave it up to the server, but I'm fine with forbidding it also I guess.

MaxF12 commented 2 years ago

I guess to me it's also about separation of concerns where the multicast session is just data and all the control data goes over the unicast connection. Though I guess due to PATH_CHALLENGE frames that won't be entirely possible either way so I agree with your "meh", I guess in the end it won't matter.

GrumpyOldTroll commented 2 years ago

Ah, I see. I was thinking more like "data is data", and data that's the same for a whole bunch of clients is useful to send over multicast whether it's control or application data. I was basically aiming to disallow only those frames that don't make sense because of the "unidirectional alternate path" part.

Similar to PATH_CHALLENGE, I think things like PING and PADDING might be needed just for practical purposes, and the INTEGRITY frames are I think pretty useful to permit over other multicast sessions, since they otherwise make a new unicast scaling limit. (I guess that shouldn't really matter if you're scaled appropriately to have a graceful full-unicast fallback the way you should be, but it seems like even 3% of the unicast baseline can get to be a lot so it's potentially worth offloading...). The other frames are maybe less important, but I didn't see a reason to exclude them.

Improving security would be a good reason though. But even there, if there's a threat model from a pervasive monitoring attacker getting a key leaked from some unicast context and then losing that access but staying joined to follow all the key updates (whereas he'd otherwise have to keep access to a unicast endpoint), then it seems to me the right answer might be to put the key updates on the unicast channel, but other changes to mutable properties on the multicast channel still could be usefully sent over the session, since they're the same for everyone. (The changes for the keys and for the other things could just be sent in separate MC_SESSION_PROPERTIES frames.).

Anyway, I guess I'm thinking to close this for now if we're both 'meh', and either reopen or make a new issue if we later find a reason it makes a difference.

MaxF12 commented 2 years ago

Actually, I had another idea: if the only issue is forward secrecy, what if a recommendation is added that every nth MC_SESSION_PROPERTIES should be delivered over unicast to break the chain of endless forward secrecy violations?

GrumpyOldTroll commented 2 years ago

That seems reasonable.

But this is more like every N key rotations, and only has to count updates containing a new key, updates to other properties probably shouldn't be counted.