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

Hi Dave,

I'm not sure, I understand your use-case here.

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.

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.

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.

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
> 