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