[xmppwg] [Fwd: [Security] where do the security bits belong?]

Peter Saint-Andre stpeter at stpeter.im
Tue Mar 3 18:59:09 CST 2009

FYI. Follow-ups here:




The XMPP Council will discuss this in its meeting tomorrow at 20:00 UTC:



-------- Original Message --------
Subject: [Security] where do the security bits belong?
Date: Tue, 03 Mar 2009 12:05:25 -0700
From: Peter Saint-Andre <stpeter at stpeter.im>
Reply-To: XMPP Security <security at xmpp.org>
To: XMPP Security <security at xmpp.org>

I've started reviewing all the Jingle specifications for one final
read-through, and it struck me that the security-related bits are now in


The primary driver for this work is indeed end-to-end encryption of XMPP
traffic as explained in that I-D, but the <security/> element could also
be used to provide a "security context" (not sure if that is the proper
phrase) for a streaming or datagram transport that is used with any
application type.

So there really are three different moving parts here:

1. The application type. The urn:xmpp:jingle:apps:xmlstream:0 namespace
from the I-D defines a new application type for end-to-end XML streams,
which we strongly recommend that you do over a secured transport (else
what is the point other than escaping the tyranny of rate limits?).
However, you could also do file transfer (XEP-0234) or VoIP (XEP-0167)
or any other Jingle application type over a secured transport.

2. The transport. As explained in XEP-0166, the transport can be
streaming (in-band bytestreams, SOCKS5 bytestreams, ice-tcp, etc.) or
datagram (raw UDP, ice-udp, etc.) Adding "XTLS" into the mix changes the
dynamics of session negotiation, which is pretty core to Jingle as a
negotiation framework.

3. The security context (a.k.a. "XTLS"). Until now, no Jingle transport
methods had a security context (or, to be precise, they had a null
context). But the urn:xmpp:jingle:security:xtls:0 namespace defined in
the I-D adds a <security/> element to any Jingle negotiation, which can
be used to establish a security context via "XTLS", i.e., TLS for a
streaming transport and DTLS for a datagram transport.

My question is, where does the definition of XLTS really belong?

It feels odd *not* to define it in XEP-0166, since that is the core
Jingle spec and the addition of security contexts changes how sessions
are negotiated. If we did that, draft-meyer-xmpp-e2e-encryption would be
rather brief because it would define only the combination of the
end-to-end XML streams application type, a streaming transport (most
simply in-band bytestreams), and a security context.

On the other hand, if we define security contexts in an Internet-Draft
then it is more likely to receive proper security review within the
IETF. However, at that point it seems that we might be bringing in a
whole raft of dependencies. Perhaps that is manageable (I don't think
it's appropriate to suddenly move all of the Jingle specifications to an
XMPP WG!), but I want to make sure that we can manage this work in such
a way that we receive the proper security reviews for XTLS without
burdening the IETF with masses of new work.

Finally, somewhat of an aesthetic point is that I'd really like to have
only one document that defines end-to-end encryption of XMPP traffic,
rather than forcing a developer to read a spec on end-to-end XML
streams, a spec on Jingle security contexts, and so on. Perhaps that is
not so important in the end, but I'd appreciate feedback about it from
client developers.



Peter Saint-Andre

Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/xmppwg/attachments/20090303/2ca9ae62/attachment.bin 

More information about the xmppwg mailing list