[Arathorn]

All the pointing-and-laughing derision on the podcast seemed pretty toxic, tbh. Rather than all the "oh look how stupid Matrix are" schtick, it might have been even more interesting and informative (and less obnoxious) to get the other viewpoint and understand why we don't consider server-controlled group membership to be catastrophic in practice... as per my explanations elsewhere on the thread.

Honestly, this whole thing shows the infosec community at its worst: optimising for sensationalism/drama/press-coverage over constructive criticism and research. And it's particularly grating when the target is a mission-driven non-profit FOSS project, rather than a bungling megacorp vendor or whatever. Meanwhile things like OpenSSL RCEs or even Signal RCEs like https://thehackerblog.com/i-too-like-to-live-dangerously-acc... fly past without the researchers doing the podcast circuit(!)

[tptacek]

By all means, jump on an episode with us, and give us the other side.

We're offensive cryptography (in the "offense" vs "defense") people, and have a warm, effusive enthusiasm for offensive research results. It stings to hear enthusiasm about attack research that impacts your project, but that's not the intent, of course. You'd hear exactly the same tone if we were talking about some hypothetical system.

Meanwhile, I can't disagree more strongly with your last paragraph. This is a sensational result. It's the most impactful result ever generated against a secure messaging protocol. It deserves whatever attention it can get. To date, I think the Matrix project has been quite effective at diverting attention away from the results.

I think you'll find that even non-event OpenSSL vulnerabilities get multiple bites at the HN front page. Every serious OpenSSL vulnerability in the last 10 years has gotten vastly more attention than this research.

We do this podcast under our own names, with our own professional reputations attached, and we should all be able to at least agree that we've got a lot invested in those reputations. If we record an episode with the Matrix team giving their side and treat you unfairly, people will hear it, and that will reflect poorly on us. Apart from us just not being, like, monsters, our incentives are also aligned to give you a fair hearing.

Let's do an episode where you explain why this isn't as big a deal as we made it out to be! We're game.

[Arathorn]

> Let's do an episode where you explain why this isn't as big a deal as we made it out to be! We're game.

Sure, sounds like a plan. In order to actually present a balanced view and not end up with another one-sided episode like the last one, you might want to get the researchers involved again too.

And to be clear: my biggest issue with the podcast was the amount of (literal) laughing and derision and general "oh look how stupid they are" obnoxious attitude, rather than the claims of the paper. Our only point of contention with the paper is over whether server-controlled group membership is as big a disaster as you claim it to be, given you have to verify users to avoid interception anyway, at which point malicious devices are clearly flagged so clients can take evasive action (e.g. big red warnings, or refuse to encrypt messages in that room, etc.). From a purely theoretical perspective: yes, it's a bug that a server can add ghost devices at all. From a practical perspective, please show me the attack where a server or HTTPS MITM can add ghost devices to a verified user without the malicious user and room turning bright red like a TLS cert warning.

Anyway, once we've landed the TOFU and client-controlled-membership work (which is already overdue) I'd be very happy to come on the show to explain how the mitigations work, where the issues came from in the first place, and why we think the paper seriously overclaimed (which is a shame, given the actual implementation vulnerabilities were great research).

Thanks for the invite! :)

[DyslexicAtheist]

I'm absolutely rooting for you doing an episode together. please listen to some other episodes before dismissing the content because of format - they're fantastic.

> whether server-controlled group membership is as big a disaster as you claim it to be, given you have to verify users to avoid interception anyway, at which point malicious devices are clearly flagged so clients can take evasive action (e.g. big red warnings, or refuse to encrypt messages in that room, etc.).

I really would love to see this addressed: the UE of crypto. In 2022 we should absolutely refrain from leaving the decision to the user w.r.t if it is safe or trustworthy. Users suck. Don't trust users to look at warnings unless you're intention is to cater to only those of us who still have a GPG FPR in their ~/.signature

It. Does. Not. Work.

"Web of Trust" was a great idea but failed to scale (when was the last time you received a gpg encrypted mail from anyone).

Signal served us well until SGX.fail (https://sgx.fail), and it's why something like Matrix deserves to succeed.

Systems get better under pressure (when questioned) so I really hope y'all get a chance to talk.

[Arathorn]

> In 2022 we should absolutely refrain from leaving the decision to the user w.r.t if it is safe or trustworthy. Users suck. Don't trust users to look at warnings

Yup, totally. Which is why we are addressing it. The current behaviour dates back to 2016, and reflects the transition from plaintext to e2ee matrix which happened between then and now - much as TLS browser warnings have evolved in the same timeframe, and eventually being replaced by HSTS and friends. It doesn’t mean that the previous behaviour is catastrophic though - just as browser warning semantics doesn’t kill TLS.

[tptacek]

Hit us up! You can email me at the address in my profile, and David and Deirdre will work with y'all to figure out a schedule.

[Arathorn]

Will do. Just want to land at least the tofu work first, as fun as it’d be to sit there saying “coming soon” on loop.