[Security] XMPP encryption summary from IETF 74

Dirk Meyer dmeyer at tzi.de
Fri Apr 3 03:08:22 CDT 2009


sorry for the late answer, there are some problems here with our mail
server not liking the xmpp list anymore.

Peter Saint-Andre wrote:
> 1. Why Not Use OTR?
> Many IETFers use OTR to encrypt their IM traffic, so they wondered why
> we don't just use OTR. The last time I looked, I think there was only
> one library for OTR, so that might be a problem (also it is not fully
> XMPP-friendly because it was designed for cross-protocol IM only, not
> encryption of complete stanzas etc.).

Don't we have the same problems with OTR as we have with ESessions?

a) We need a security review if OTR is as secure as it claims to be
b) Does OTR work with IQ stanzas?
c) If there is only one library, we lack inter-op tests if the lib
   really does what the specs says.

> Some folks didn't like the idea of XTLS because it is stream-based, not
> message-based. In particular, Pete Resnick [cc'd here because he's not
> on the list] noted that XTLS can't handle offline messages and so
> doesn't address all the use cases (as he put it, it seems silly to have
> one technology for encrypted communication when the other party is
> online and a different technology for encrypted communication when the
> other party is offline). Note that this objection applies only to
> end-to-end chat, not things like secure file transfer, since they go out
> of band.

So we have end-to-end chat, offline chat, and other things like secure
file transfer. Where is the difference between

a) Use XTLS and something different for offline messages and
b) Use something like OTR for chat and something different for FT

I don't see THE solution that works for all cases.

> 3. Streaming Handshake, then Object Encryption?
> One possible approach we discussed was to use a TLS (or TLS-like)
> handshake to bootstrap trust or exchange keys, then to use object
> encryption after that for XMPP-native encryption. The use of TLS would
> then be restricted to Jingle (i.e., "this transport must be secured via
> TLS or DTLS before exchanging application data over the channel").

If you opened a TLS session to bootstrap Object Encryption, why remove
the TLS layer after that. It is already secure. Reading RFC 3923 Section
5 I wonder how IQ stanzas should be encrypted. The same as message and
iq with:

<iq from='' to='' id=''>
  <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>

Like Justin wrote: that could be a good idea for offline messages and
keep the rest as it is.

> 5. JavaScript Clients
> More and more XMPP clients are being written in JavaScript. But there is
> no SSL/TLS stack for JavaScript. Furthermore, the dependency on X.509 is
> problematic because there is no ASN.1 support in JavaScript, either.  (I
> also note that there is no OTR library for JavaScript.) If we can define
> something significantly simpler than XTLS or RFC 3923 or OTR, we would
> make it possible for JavaScript clients to play in this space. These
> considerations might lead us to favor something like (1) bare keys
> instead of self-signed X.509 certs [your key could in turn be signed by
> your X.509 cert or OpenPGP key if you have one], (2) TLS-like handshake
> instead of full TLS, (3) basic CMS [RFC 3852] instead of S/MIME, etc.

Encryption in JavaScript ... *shiver* ... I'm not sure how the
performance of RSA written in JavaScript would be.

On the other hand I'm not sure you can get end-to-end security if you
download the code on-the-fly from the server. JavaScript is not the only
language with problems, a J2ME client will also not work. The question
is: do we care? If we do, we need something much simpler and self-made
(I hate to say it, but ESessions comes to my mind). Or we ignore it and
assume that future browsers may have an XMPP stack inside or at least
have TLS/SRP support.


Standards are industry's way of codifying obsolescence.

More information about the Security mailing list