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

[Simon Josefsson <[e-mail]>]

Martin Thomson <[e-mail]> writes:

> On 29 October 2015 at 09:02, Martin Thomson <[e-mail]> wrote:
>> I don't think that Axolotl is a good model
>> for the general use case.
>
>
> Since Florian asked nicely, here's the text I wrote about a year ago
> regarding PFS:
>
>>>>
> 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.
>
> We value function over perfect security and consider logging to be a
> critical part of a functional chat system.

I believe there is a logical mistake here -- supporting logging does not
mean you cannot support forward security.  I'm firmly on the side that
logging is an essential property of a chat system that I would use,
however I acknowledge that NOT logging is an essential property of a
chat system some other people would use.  While forward security is less
critical to the first category (something I'm not sure I would agree
with fully), it appears essential to the second category.  A system that
supports forward security appears more general to me than one that
doesn't.

I would welcome a detailed analysis of pro's and con's between this
proposal and OMEMO, to identify if there is anything the OMEMO approach
could learn and pick up from this approach.

/Simon

> Furthermore, forward secrecy requires that a round trip between two
> parties occurs to establish a properly ephemeral key. This means that
> any initial message to any other device either cannot have forward
> secrecy, or it cannot include any content. In the latter case, content
> could only be carried once the receiving device has replied with their
> ephemeral share. (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.)
>
> 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.
> <<<
>
> I think that there was a separate note about the value of PFS for some
> exchanges.