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

--===============7845485580816441354==
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha256; protocol="application/pgp-signature"

--=-=-=
Content-Type: text/plain

Martin Thomson <[email protected]> writes:

> On 29 October 2015 at 09:02, Martin Thomson <[email protected]> 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.

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJWOhiOAAoJEIYLf7sy+BGdCc8H/1Tr5IFb0XDmvirrgqtIGCxI
IcGzATHAUd/nX5xMxbjDbjUItxK3BL/PROsagB8IHAu87mMvw76zyACjan6F1d4m
APahdMTSifN/mBR2KA/TPPDpfNjajnbgCLiNCNaFPy0OQq97HAKhSslv9cHcVenl
CV88XxJOuZY8FIm3Wyhfvhw0RVff45T06LdQahg6jSKzoHy1EoLeEkAaP3fJ8CCK
RsCzIoBrereSqCeO7UfsGYQ/KK1+/8qSIw+DTMFhlwp31G4YJeDwgQ6sqzMkLxYP
OU0xey6Iayawm5jMIAppmUStJK0eEvf6ABCh1TRswd4zmSPsyPC1uN4rSu+hHo4=
=3doO
-----END PGP SIGNATURE-----
--=-=-=--


--===============7845485580816441354==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
xmpp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/xmpp

--===============7845485580816441354==--