[HN Gopher] RFC 9420 a.k.a. Messaging Layer Security
___________________________________________________________________
RFC 9420 a.k.a. Messaging Layer Security
Author : jakobdabo
Score : 137 points
Date : 2023-07-21 16:19 UTC (6 hours ago)
(HTM) web link (blog.phnx.im)
(TXT) w3m dump (blog.phnx.im)
| mananaysiempre wrote:
| At the risk of falling afoul of the site guidelines, can I
| complain about an _un_ common annoyance? Apparently this blog
| pulls a Facebook, or more precisely a fbclid, and adds
| ref=blog.phnx.im as a query parameter to every link. This seems
| less than fitting for a post on a privacy technology, and
| actually breaks the link to the IETF BoF minutes[1].
|
| [1]
| https://datatracker.ietf.org/meeting/101/materials/minutes-1...
| eps wrote:
| Oh, the irony.
| wkrp wrote:
| That's something ghost.org does by default. I unknowingly ran
| into the same issue for my blog.
| saurik wrote:
| Does 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).
|
| https://github.com/mlswg/mls-architecture/issues/50
| jeroenhd wrote:
| 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 protocol if it does get implemented.
| lxgr wrote:
| > 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):
|
| https://signal.org/blog/simplifying-otr-deniability/
| Arathorn wrote:
| afaik MLS doesn't currently support deniability. This means you
| can have attack where a member of the group conversation can
| prove in retrospect that an encrypted message was sent by a
| given sender. This is a big deal if you want to be able to talk
| freely without being blackmailed - for instance, I might want
| to say something to a given user intended only for their eyes,
| and if they then take that info and show it to other people
| (e.g. to blackmail me), I want to be able to claim that they
| faked the screenshot or otherwise fabricated the message. I
| certainly don't want some sort of signature on the message
| undeniably tying it back to me.
|
| Now, Double Ratchet (and Olm and Megolm in Matrix) provide
| cryptographic deniability by using MACs rather than signatures
| for integrity, meaning that any given message could have been
| faked by the other participant in the conversation (given they
| know the secret that would allow them to encrypt that message
| themselves).
|
| However, it's worth noting that _practically_ speaking, a
| malicious server admin could turn up with some snapshots of
| their DB or some server logs with the ciphertext in them and
| say "i can prove that that screenshot's not faked, because my
| server saw that encrypted message sent from that user". And so
| _if_ the admin was trusted (i.e. not colluding with the
| blackmailer), that could be seen as sufficient evidence to
| break deniability, albeit not at a cryptographic level.
|
| So, basically: deniability is subtle - it's not obvious that
| cryptographic deniability is always a big win, given one can
| often find non-cryptographic ways to sufficiently prove that a
| user sent a message. That said, if you _don 't_ have
| cryptographic deniability, then you can be sure that a
| malicious conversation participant equipped with a suitable
| client which has forensics mode enabled will be able to produce
| evidence that cryptographically proves that you indeed said a
| given sensitive statement, whether you like it or not.
| simonpure wrote:
| This proposal depends on a central server and there is an
| alternative decentralized proposal -
| https://eprint.iacr.org/2020/1281
| Klasiaster wrote:
| There are plans for using it in Matrix: https://arewemlsyet.com/
| (pointed out in https://news.ycombinator.com/item?id=36777573)
| mhoad wrote:
| Same deal with Google Messages
|
| https://security.googleblog.com/2023/07/an-important-step-to...
| lxgr wrote:
| 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.
| phh wrote:
| Yeah no. Google Messages (almost) always go through Google
| services, not carriers. They are definitely their own
| platform.
| cpach wrote:
| Link in case anyone else is curious about RCS:
| https://en.wikipedia.org/wiki/Rich_Communication_Services
| jeroenhd wrote:
| Full 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.
| goferito wrote:
| What 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?
| Zamicol wrote:
| 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.
| woah wrote:
| One big difference is that the authors of this protocol have
| probably spent a lot of time at IETF meetings
| mananaysiempre wrote:
| The Matrix spec defines everything about how communication
| should happen--port discovery, federation, transport, wire
| formats, encodings, schemas, addresses for people, group
| membership, reconciliation of parallel histories, ..., and,
| yes, end-to-end cryptography. MLS is just the end-to-end
| cryptography part, how to turn it into bits, and a general idea
| of where the underlying network should deliver those bits.
| Nothing about how the delivery is accomplished or how to format
| the user data that's protected by the cryptography.
|
| The corresponding part of Matrix is called Olm (for two-party
| conversations) and Megolm (for groups). Why (a Matrix mapping
| of) MLS and not those then? The Matrix people, who did have a
| hand in MLS, say[1] it performs better than Megolm, and IIRC
| Megolm is indeed something of a hack on top of plain Olm,
| because E2EE on Matrix has been built up gradually starting
| from the simpler two-party case. Unfortunately, it looks like
| MLS as specified is insufficient for Matrix, because it relies
| on a global clock--which you can't get in a partition-tolerant
| federation--but they think that should eventually be
| solvable[2].
|
| [1] https://matrix.org/blog/2023/07/a-giant-leap-with-mls/
|
| [2] https://gitlab.matrix.org/matrix-org/mls-
| ts/-/blob/decentral...
| Arathorn wrote:
| Decentralisation-friendly MLS is working well already as a
| proof-of-concept in Matrix - check out the Implementation
| section of https://arewemlsyet.com :)
| upofadown wrote:
| The killer feature here is efficient handling of very large
| groups. That's great but that isn't the main issue with this sort
| of thing.
|
| Identity in end to end encrypted group messaging is hard to do.
| This seems to leave the difficult identity issue to future work.
| How do we know that we are due to have a breakthrough in the near
| future?
|
| Even if they do come up with something usable in a technical
| sense, there is no way you are going to know who all the
| participants are in a large group. The problem is to some extent
| inherently unsolvable.
|
| Interoperable 1 to 1 end to end encryption might be a better
| first try.
___________________________________________________________________
(page generated 2023-07-21 23:00 UTC)