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

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
>