Re: New(ish) draft: Secure Messaging in XMPP

On 30 October 2015 at 03:05, Andreas Straub <[email protected]> wrote:
> 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.

I think that you will find that the proposed design does have the
ability to perform frequent key updates for both symmetric and
asymmetric keys.  It's just that we don't have anything that would
allow something like the Axolotl per-message switch.

>> (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?

Elaboration was in the next paragraph :)  I don't think that there is
much more to it.

>> 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.

My experience with this is that this is far from unusual, rather that
it is the norm that one or several participants in a discussion are
offline, potentially for extended periods.  The real challenge is in
deciding if you are willing to cut them out of the conversation
entirely at some point.

>> 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.

Ultimately I agree.  I think that the only place we might disagree is
how far toward the ideal we intend to aim.