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

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 <dave@cridland.net>:
>On Thu, 23 Jan 2020 at 14:55, Konrad Kohbrok
><konrad.kohbrok@datashrine.de>
>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 <cas.cremers@gmail.com
>> > <mailto:cas.cremers@gmail.com>> 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
>> > MLS@ietf.org
>> > https://www.ietf.org/mailman/listinfo/mls
>> >
>>
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/mls
>>