Re: New(ish) draft: Secure Messaging in XMPP
Thijs Alkemade <[email protected]> Sat, 24 Oct 2015 10:55:17 +0200
| Newsgroups | gmane.ietf.xmpp |
|---|---|
| Message-ID | <[email protected]> |
--===============2112680177670006368== Content-Type: multipart/signed; boundary="Apple-Mail=_1BD9529D-6C3B-473B-91D0-1D2A81EE5906"; protocol="application/pgp-signature"; micalg=pgp-sha256 --Apple-Mail=_1BD9529D-6C3B-473B-91D0-1D2A81EE5906 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23 okt. 2015, at 23:18, Adam Roach <[email protected]> wrote: >=20 > XMPP folks: >=20 > Martin and I put together a proposal for an approach that allows for = end-to-end encrypted XMPP conversations, including in the presence of = MUC. Although not a completely implementable spec, this should give a = good idea about the direction we have in mind: >=20 > https://tools.ietf.org/html/draft-thomson-xmpp-secure-00 >=20 > Anyone interested in this work should give it a read and provide = feedback. In particular, I'm curious if anyone interested in = implementing this kind of thing has requirements can't be addressed with = the high-level approach we're describing. >=20 > Thanks! >=20 > /a Hi Adam, I've read through the draft, and there are still some things unclear to = me. Forward secrecy is never mentioned. =46rom the design, I can't tell if = it was a requirement. The symmetric key that is generated in =C2=A76.2 can be = decrypted by anyone who has a log of all stanzas and the private Diffie-Hellman key = of either party. The symmetric key has a limited lifetime, but that is not enough = if the DH keys do not expire and I don't see the document mention that they do. The support for offline messaging is also a bit unclear to me. =C2=A76.4 = suggests that a client can send a Symmetric Key Advertisement to a client that is currently offline. But how would the sender obtain the DH public key for = the recipient if that key is advertised using presence (as stated in =C2=A76.1= )? The receiving client would also need to wait for the sender to be online to = obtain its DH public key before it can decrypt the key. (And the sender would = be unable to change their DH key until all advertisements have been acknowledged, destroying forward secrecy.) To be honest, I think the current OMEMO draft, while not perfect, = matches my requirements a lot better. Regards, Thijs --Apple-Mail=_1BD9529D-6C3B-473B-91D0-1D2A81EE5906 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJWK0d3AAoJEDJpbwxQSdU3fR0P/RwEmq/hdyajKESMu2wqYnpw 7KwNxs3yyTd/Sgm17h3xDnKCgpBWW9p0fesKp+JNDC152UuMHuNfZixui/piHYDr geOsS9D9Mcw870M7pR+Loja79b0KugX9N+PZMrxeQZHR89SW/JVetTH3cStJvRE2 kFvUCIakgNQ6f1ueDQ3Wafx884l7hhYrk9rZVtjAcropXMppVwq8oyJ8dnH/gdeL wPUA7E9qSZkhn4GPZ+4PTaLKgNAju2sTPW3XHsa1RJjsgHINvoFeCDeyIacPGMTp WeFiNmsZG1KGCbVdisZVc1JC1v5xIZ3Wdbzd1VOkgumEWIf3sExulDydgiULb25U VE3lTvRfocStPi4pQPpYKSBALXAC5WJGttBDbPvH+ZDSN3HAoLFX2r1sWrjc/L8k 1LbdFnh7IRy6UQyEA57rtk91MvD7wkFyf7gg4oxh4qWEUfGivunowoyOZShfNOTU eawGfOnVsq/wGRnvEmcpwMA2kfpz9+qa58bRONkorgmeEfFNG7c88Bg5zxXsKbKd ngmC2q4WNGAckv3fJBVIm1+IHW32kJbxnPuehSMZkH/SgbbTaThxVZP4w8ZcJU3/ w7cbIn0/vsOIGtRnRZxzfXk/SD5J/Wmaq3oHCBX/UChdrM5loRKHChHD1sd7P4J0 2y9KSxRvG7VL0XT6i8X/ =rMNi -----END PGP SIGNATURE----- --Apple-Mail=_1BD9529D-6C3B-473B-91D0-1D2A81EE5906-- --===============2112680177670006368== 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 --===============2112680177670006368==--