You wanna see a fucking threat model?

Here: https://github.com/fedi-e2ee/public-key-directory-specification/blob/main/Specification.md#threat-model

And this is for an ActivityPub service that just stores data in immutable plaintext and serves it over HTTPS!

@soatok This is comically bad at defining anything at all.

So many of them aren't even like, threats that I (personally) would expect a protocol to handle? Like maybe there's a way to avoid checks matrix documentation "An attacker could send large volumes of messages to a chatroom with the victim making the chatroom unusable" at that level, but that... that's surely a moderation tooling issue, not anything to do with security? You give users the tools to remedy that problem when it arises. Yet I can't tell by what means that's "addressed" (let's be real, it isn't).

I imagine not very many people who haven't dug deep into exactly how Matrix works at its core can really look at this appendix and get a remotely decent understanding of what, exactly, is happening other than "yeah these can happen."

I'm no cryptographer, but similar to your statement of "It's either an A, A-, or an F" rings very true in the power and controls industry. Edge cases cannot exist if they are found - they must be designed to prevent or handled smoothly should it be impossible to actually avoid. The last thing you want is to trigger an unintended operation (UO), especially automatically, with no input from an operator.

I had to deal with writing some totally janky code to handle a pretty gnarly UO that'd happen whenever there was a failover between two devices that talked to a single human-machine interface. For some GOD FORSAKEN REASON the HMI of choice could be configured to connect to two servers (DNP parlance) but it couldn't maintain an active connection between the two. If it lost connection and had to switch to the other server, a lot of data could be completely overwritten by the HMI since again, for some god forsaken reason analog output values are only set on-input in HMI, and then are fucking zeroed out. When it switched over, it would then re-send the goddamn zeroes.

I forget how exactly we prevented that from happening, IIRC it boiled down to the controllers storing the analog setpoints separately from the HMI's connection and basically ignoring whatever the HMI sends until it confirms the connection was fully established. It was clunky, there was almost certainly a more elegant solution, but we were strapped for time since this came up mid-commissioning and a proper fix was needed ASAP.

(at least there's good news, in the most recent version of the HMI that was being a little shit, it can now actually talk to both units at the same time which hopefully theoretically removes that problem in the first place. I don't know, I haven't gotten to work with it, and even if it can talk to both at the same time that doesn't resolve the "sending zero values" UO.)

anyways good lord that "threat model" from Matrix is garbage. Reading through what I could parse of yours, it's y'know. Actually defined how exactly things could be or are a problem, and how they relate to another. Much better, and also much appreciated since it makes it easier to validate whether the functionality satisfies the model presented and the goals for what can and cannot be done at a protocol/design level.