Re: [xmpp] New(ish) draft: Secure Messaging in XMPP

[Andreas Straub <[e-mail]>]

Hi,

I'm the person behind the OMEMO spec, so I'm obviously a bit biased, but
I thought I would weigh in on this specific point.

> For a system where the messages are stored, this is largely a
> pointless exercise. Destroying the messages is also necessary to
> ensure that they cannot be recovered.

I feel strongly that there's nevertheless a significant benefit to be
gained from some form of forward secrecy. It's still the difference
between an attacker having to break one secret and being able to decrypt
the entire history, versus having to break one secret per message (or
sub-chain in the axolotl world). I would actually argue that in a
stored-messages scenario, frequent key update is *even more important*,
because the impact of a broken secret can be so much higher.

> (Other systems address this in part by provisioning a
> public store with shares ahead of any need for others to use them, but
> these systems work poorly in multi-party scenarios.)

Are there any specific problems with multi-party scenarios you could
elaborate on? We've been using just this approach with OMEMO (and I'd
argue it's been pretty successful so far), so I'd be very interested if
there is something that we've neglected to consider here.

> In the case where there are multiple agents in a chat - a scenario we
> consider to be critical for usability reasons - if any one user agent
> is offline, any message encrypted for that agent has to use a key that
> can only be unilaterally updated. Messages destined for the offline
> agent will necessarily depend on the private keying material on that
> agent, which cannot be updated.

You make a good point here, in that conversations that involve a device
that is offline for long periods of time must necessarily degrade their
forward secrecy accordingly.  However, this is not necessarily the
average use-case. In fact, its a rare edge case. I would argue that a
protocol which always provides the highest level of forward secrecy that
is possible in any situation is preferable, even if in certain
pathological cases, the security will degrade to a fixed-secret
equivalent level.

> We value function over perfect security and consider logging to be a
> critical part of a functional chat system.

I agree wholeheartedly. People have come to expect such features from a
modern instant messaging service, and rightfully so. But OMEMO actually
achieves these while also providing forward secrecy. I don't think that
we should give up on forward secrecy altogether just because we can't
achieve *perfect* forward secrecy in every situation.

Cheers,
Andy