Re: [MLS] Deniability -> "recording"?

[Raphael Robert <[e-mail]>]

It seems there is some confusion around the properties. Deniability has always been considered as an optional property, this is clearly stated in the architecture document:

"As described in {{client-compromise}}, MLS provides strong authentication within a group, such that a group member cannot send a message that appears to be from another group member. Additionally, some services require that a recipient be able to prove to the messaging service that a message was sent by a given client, in order to report abuse. MLS supports both of these use cases. In some deployments, these services are provided by mechanisms which allow the receiver to prove a message's origin to a third party (this if often called "non-repudiation"), but it should also be possible to operate MLS in a "deniable" mode where such proof is not possible.”

This means that for use cases where deniability is not required or even allowed (perhaps because of compliance rules in certain industries) vendors can simply chose to not use the deniable mode of MLS.

As Konrad mentioned, FS is not optional and at the core of MLS. For use cases where FS is not desired for actual application messages and instead you want a long term symmetric key, MLS can be used to distribute this key securely among members. These use cases would require a (rather thin) layer on top of MLS that handles symmetric encryption/decryption.

Raphael

> On 23 Jan 2020, at 16:47, Konrad Kohbrok <[e-mail]> wrote:
> 
> The record keeping doesn't have to be in the nurse's phone. You can simply mandate that by default a recording service is added to every conversation. That service can run on a well-secured server.
> 
> Implementing or even deploying MLS is certainly not going to be a trivial task. However, I would argue that running your own message encryption on top of MLS (which I can't imagine why you would want that, see above) is more hassle than simply signing messages on top of MLS.
> 
> Konrad
> 
> Am 23. Januar 2020 16:35:48 MEZ schrieb Dave Cridland <[e-mail]>:
> 
> 
> On Thu, 23 Jan 2020 at 14:55, Konrad Kohbrok <[e-mail] <mailto:[e-mail]>> wrote:
> Hi Dave,
> 
> I'm not sure, I understand your use-case here.
> 
> 
> I work for Pando, doing clinical messaging within the NHS in the UK, and elsewhere. Quite happy for the NHS to read doctors' and nurses' messages about patients, less happy for us to be exposed or for anyone who picks up a nurse's phone.
>  
> Regarding FS: Any participant is free to just keep a log of the plaintexts, thus
> circumventing any FS guarantee. If you want to log the keys, any party can do
> that as well. If I'm not mistaken could also simply opt not to use an RTreeKEM
> ciphersuite and never update the recording party's leaf key.
> 
> 
> We can't, actually, but as I say we can export a stable key for message encryption at each epoch so we're covered.
> 
> (We cannot keep a log of the plaintexts since that would place persistent plaintext data on the user devices which would be problematic for us, since it's patient data).
>  
> Regarding deniability: Similarly, any member of a group can simply sign their
> messages using their static identity key at the application layer. This would
> effectively destroy deniability, but it is up to the application to make that
> decision.
> 
> Yes, that would probably work.
> 
> I guess my point is that destroying deniability (and FS) at the application
> layer is easier then getting it if it is not built into the protocol in the
> first place.
> 
> Almost certainly; though this is an ever-increasing number of hoops to jump through. My concern is that baking in a very particular definition of "security" runs the risk that it either outright prevents the use in some cases, or simply prices people out of the market in technical knowledge terms.
> 
> I am already going to end up writing much more cryptographic code than I'd like to use MLS. Writing more doesn't fill me with confidence.
>  
> 
> Cheers,
> Konrad
> 
> On 23.01.20 15:30, Dave Cridland wrote:
> > 
> > 
> > On Thu, 23 Jan 2020 at 13:59, Cas Cremers <[e-mail] <mailto:[e-mail]>
> > <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
> > 
> >     We're aiming for security first, I think.
> > 
> > 
> > If we mandate deniability and mandate PFS, then the risk is that the threat
> > model ends up less applicable.
> > 
> > We can work around the PFS by (in effect) using MLS as a groupwise key exchange
> > protocol and exporting a longer term key for message encryption, but if we
> > destroy cryptographic integrity post-facto, as I assume we mean by deniability,
> > then that makes life increasingly unpleasant for the cases where people actually
> > want different properties.
> > 
> > In short, preventing various groups making use of MLS is not security first.
> > 
> > Dave.
> > 
> > _______________________________________________
> > MLS mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>
> > 
> 
> _______________________________________________
> MLS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls