[HN Gopher] RFC 9420 - A Messaging Layer Security Overview
       ___________________________________________________________________
        
       RFC 9420 - A Messaging Layer Security Overview
        
       Author : todsacerdoti
       Score  : 106 points
       Date   : 2023-11-11 07:34 UTC (2 days ago)
        
 (HTM) web link (www.thestack.technology)
 (TXT) w3m dump (www.thestack.technology)
        
       | isodev wrote:
       | I just can't help but wonder if RFC9420 has had enough time to
       | mature enough to offer sufficient features to be adopted
       | by/replace say Signal (Whatsapp, iMessage) and similar solutions.
       | The group key security sounds nice, but the lack of end to end
       | authentication or message integrity/sender signing does not feel
       | very reassuring.
       | 
       | It feels like some design decisions and compromises have been
       | made in order to optimize the use-case for large group chats at
       | the expense of some safety aspects that exist today in current
       | protocols.
        
         | ekr____ wrote:
         | MLS provides end-to-end integrity via signatures.
         | 
         | https://www.rfc-editor.org/rfc/rfc9420.html#name-content-aut...
        
         | camgunz wrote:
         | AFAIK at least Element/Matrix are actively working on adopting
         | it.
        
           | Arathorn wrote:
           | https://arewemlsyet.com for the Matrix progress
        
         | monocasa wrote:
         | Given what I saw at the MLS working group meeting at IETF last
         | week (as in what'll be all of MLS, not just RFC9420), it's
         | actively being worked on by people who share your concerns. The
         | higher levels of the stack concerned with "what are all of the
         | options for what's inside an actual message" are under active
         | development, both code and standards work. Those writing code
         | will almost certainly have to change their implementation to be
         | interoperable with the final standards there, but IMO bless
         | them for coming to these meetings with "I tried to implement
         | it, it's broken for these reasons you can see in code here".
        
       | exabrial wrote:
       | Most E2E systems require some sort of long term identity key with
       | the other person(s), I assume MLS is the same? (this is a good
       | thing IMHO)
       | 
       | If so, I would really like this to be flexible enough to say
       | derive or pull a key from PGP, and/or a verifying service/website
       | (such as Keybase). I'd really like to move away from "Your cell
       | phone number is your identity" to a "a cryptographic primitive is
       | your identity".
        
         | ekr____ wrote:
         | Yeah, MLS just assumes there is _some_ mechanism for
         | authorizing keys. Right now it just supports certificates and
         | raw keys (https://www.rfc-editor.org/rfc/rfc9420.html#name-
         | credentials) but this is extensible so you just need to add a
         | new credential type, and there are others under consideration.
        
         | EthanHeilman wrote:
         | You could use OpenPubkey [0] to bind your identity key to your
         | say Google or Okta account. With an MFA Cosigner, a malicious
         | Google wouldn't be able to impersonate you.
         | 
         | IF you really wanted to go full cipherpunk, you could use the
         | stuff risc.zero [1] is building to could keep your identity
         | secret via ZKPs on your ID Token.
         | 
         | [0]: OpenPubkey: Augmenting OpenID Connect with User held
         | Signing Keys, Paper: https://eprint.iacr.org/2023/296 Code:
         | https://github.com/openpubkey/openpubkey
         | 
         | [1]: "Under the hood is JWT and OIDC verification on top of the
         | RISC Zero zkVM" https://www.risczero.com/news/bonsai-pay
        
       ___________________________________________________________________
       (page generated 2023-11-13 23:02 UTC)