RFC 9420 a.k.a. Messaging Layer Security
blog.phnx.im
RFC 9420 a.k.a. Messaging Layer Security
1–10 of 35 posts
Re: RFC 9420 a.k.a. Messaging Layer Security
#2Does anyone know the status with respect to support for deniability / repudiation? I can't tell where they landed, and they seem to have deleted the paragraph from prior drafts that mostly left me more confused.
https://datatracker.ietf.org/doc/html/draft-ietf-mls-archite...
Previously, their designs had explicitly lacked this feature, and they said they actively didn't want it, citing "terrorism", resulting in arguments with Ian Goldberg, the developer of Off-the-Record messaging.
https://datatracker.ietf.org/doc/html/draft-ietf-mls-archite...
The arguments on the bug tracker about power imbalances were maybe a bit better, but I still personally believe this to be an important property (and one which clients need to fully embrace, allowing the ability to edit any part of the message history so easily anyone could figure out how to do it).
Re: RFC 9420 a.k.a. Messaging Layer Security
#3There are plans for using it in Matrix: https://arewemlsyet.com/ (pointed out in https://news.ycombinator.com/item?id=36777573)
Re: RFC 9420 a.k.a. Messaging Layer Security
#4Full standard: https://datatracker.ietf.org/doc/html/rfc9420
With the EU's DMA requirements coming up, this is a major candidate for a standard protocol for messenger interoperability. There's no legal requirement to support it, but implementing an existing standard that supports end-to-end encryption seems like a much cheaper and safer method than building your own.
Of course actual interoperability will depend on MIMI (https://datatracker.ietf.org/wg/mimi/about/) but this is a start.
Re: RFC 9420 a.k.a. Messaging Layer Security
#5Does anyone know the status with respect to support for deniability / repudiation? I can't tell where they landed, and they seem to have deleted the paragraph from prior drafts that mostly left me more confused. https://datatracker.ietf.org/doc/html/draft-ietf-mls-archite... Previously, their designs had explicitly lacked this feature, and they said they actively didn't want it, citing "terrorism", resulting in argum…
The last comment in the Github discussion you linked says:
We decided to handle deniability in a separate document since it will be handled via an extension.
Re: RFC 9420 a.k.a. Messaging Layer Security
#6There are plans for using it in Matrix: https://arewemlsyet.com/ (pointed out in https://news.ycombinator.com/item?id=36777573 )
Same deal with Google Messages
https://security.googleblog.com/2023/07/an-important-step-to...
Re: RFC 9420 a.k.a. Messaging Layer Security
#7Does anyone know the status with respect to support for deniability / repudiation? I can't tell where they landed, and they seem to have deleted the paragraph from prior drafts that mostly left me more confused. https://datatracker.ietf.org/doc/html/draft-ietf-mls-archite... Previously, their designs had explicitly lacked this feature, and they said they actively didn't want it, citing "terrorism", resulting in argum…
The last comment in the Github discussion you linked says: We decided to handle deniability in a separate document since it will be handled via an extension. I'm not sure what this extension looks like, but it looks like repudiation is not part of the MLS spec. I don't know how one is supposed to implement something like that through an extension, though; this sounds like it should either be a fundamental part of the…
> this sounds like it should either be a fundamental part of the protocol if it does get implemented.
You can do what the original OTR protocol did, i.e. "publish" previous authentication keys as soon as new ones superseding them are available.
But that's conceptually less elegant than what e.g. Signal does (which is to never even have non-repudiable keys available through their triple DH handshake construction, if I understand it correctly):
Re: RFC 9420 a.k.a. Messaging Layer Security
#8There are plans for using it in Matrix: https://arewemlsyet.com/ (pointed out in https://news.ycombinator.com/item?id=36777573 )
Same deal with Google Messages https://security.googleblog.com/2023/07/an-important-step-to...
I wonder how Google would actually implement that, given that "Google Messages", as far as I can tell, isn't really a "platform" (as stated in the linked article) but rather a client for RCS, which needs mobile operator support to work on Android, and to my knowledge does not work at all on iOS.
Re: RFC 9420 a.k.a. Messaging Layer Security
#9What is the difference with the Matrix protocol? Matrix is already open-source, there are libraries publicly available that implement it, both for clients and serves, in different languages. Why not just adopting it?
Re: RFC 9420 a.k.a. Messaging Layer Security
#10What is the difference with the Matrix protocol? Matrix is already open-source, there are libraries publicly available that implement it, both for clients and serves, in different languages. Why not just adopting it?
The section: How is MLS different from existing protocols?
> Secure messaging protocols in use today were designed as one-to-one protocols [...] In contrast, MLS typically has costs of O(log n) for the same scenario, making it well-suited even for large groups.