#251: Advise against absolutist DS

[ekr]

I don't understand what this is trying to say, and it seems to contradict the text directly above.

[Bren2010]

Adding further explanation. Blocking/filtering is fine, just not reliable, like you said, so DS should eventually defer to client

[ekr]

Taking a step back, the idea here is to deliver this document, not to litigate issues that are arising in MIMI. This text had WG consensus, but obviously people now believe it is imperfect, so let's ask what the minimum change we can do to make it acceptable. Given that the section is not even about filtering but rather about enforcing a consistent view of messages, I suggest we simply remove the text about filtering. I.e.,

The Delivery Service can rely on the epoch and content_type fields of an MLSMessage for providing an order only to handshake messages. Alternatively, the Delivery Service could simply apply an order to all messages and rely on clients to ignore redundant Commits.

[Bren2010]

I'm agreeable to that text. But I would also say: given that MIMI and several implementors have gotten this wrong, that makes it all the more important to find consensus, somewhere, if not here

[kkohbrok]

I'm not sure about right and wrong. In some systems, having the DS determine whether a commit is valid or invalid is a choice you can make. Sure, that choice has certain trade-offs in terms of DoS attacks, but if that's okay in your thread model, it's a valid choice. I would say we go with @ekr's minimal approach for now and then discuss if we want an additional (sub-)section that further discusses rejection of invalid commits by the DS and what that entails.

[rohanmahy]

I'm agreeable to that text. But I would also say: given that MIMI and several implementors have gotten this wrong, that makes it all the more important to find consensus, somewhere, if not here

Given? Wrong by what measure? Because for every case where you've said the DS shouldn't filter because bad thing X happens, I can show a failure mode where bad thing X happens only with clients. At least three separate implementations independently came up with DS filtering and have been using it in non-trivial environments with large numbers of groups and clients. If you wish to share your operational experience showing superior results in a variety of situations (not just theoretically) then please do. I think you have some good ideas and good insights into client-oriented approaches, some of which may bear fruit for the entire community. However, saying that everyone else "got it wrong" without evidence that your proposal solves the overall issue any better is no way to move us to consensus.

[Bren2010]

Given? Wrong by what measure?

If an implementer made a DS that says "as soon as I see a commit with epoch+1, I'm going to force every message to be epoch+1", then that allows the group to be bricked by any member sending a commit that can't be processed. If an implementer wanted to prevent the group from being able to be bricked like that, and implemented the "external rejoin" idea discussed above, then their groups can still be bricked by a single member, and they've also undermined the security of their MLS implementation. So it's wrong in the sense that it doesn't achieve the intended goal, and potentially reduces security.

I also think you might be conflating two types of filtering. The DS /can/ inspect public handshake messages and reject messages that contain proposals that violate policy. This is what I think most implementors truly care about being able to do. However, the DS /should not/ try to force a given commit to be accepted.

However, saying that everyone else "got it wrong" without evidence that your proposal solves the overall issue any better is no way to move us to consensus.

I have been making this point in various forums for months, in person, in writing, in presentations. The fact that a majority of people have done something in a certain way isn't an argument for it being secure. The MLS wg was created because secure messaging is very hard, and someone working in isolation will often implement it in a way that's subtly insecure.

[bifurcation]

I agree that this PR does not match where we ended up with in the issue discussion. It is more prescriptive, and make more assumptions about the internal structure of the DS. I have written up an alternative in #258

[Bren2010]

What assumption am I making about the internal structure of the DS?