[Standards] Proposed XMPP Extension: XMPP Transport Layer Security

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Thu Nov 1 21:41:47 UTC 2007

On Thursday 01 November 2007 12:59 pm, XMPP Extensions Editor wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> Title: XMPP Transport Layer Security
> Abstract: This document specifies the XMPP Transport Layer Security (XTLS)
> protocol. XTLS, which provides communications privacy for the Extensible
> Messaging and Presence Protocol (XMPP), enables XMPP applications to
> communicate in a way that is designed to prevent eavesdropping, tampering,
> and forgery of XML stanzas. XTLS is based on Transport Layer Security (TLS)
> and provides equivalent security guarantees. The semantics of XMPP stanzas
> are preserved by XTLS.
> URL: http://www.xmpp.org/extensions/inbox/xtls.html

I like this idea, but I'd like to see it simplified even further.  Here's some 
comments similar to ones I made when the idea was first brought up, and I 
think I may have also mentioned this in person at the devcon:

Most TLS libraries operate as a "black box", passing an opaque stream of bytes 
to the application.  I'd suggest making the XEP have a more transparent use 
of TLS to match this fact.  In other words, rather than saying the first iq 
stanza must contain certain explicit TLS constructs (e.g. ClientHello), just 
say it can contain any arbitrary TLS data, just like how a real TLS stream 
over TCP works.  This would allow most off-the-shelf TLS libraries, such as 
OpenSSL, to be used with XTLS.  Since a stanza stream has TCP-like behavior, 
I think we can get away with this.

Of course, this would mean we'd lose the direct mapping between each 
transported stanza and the content within.  For example, a single IM may span 
multiple transported stanzas, or a single transported stanza may contain 
multiple IMs.  However, I don't think having a direct mapping buys us much at 
all, while having an opaque/transparent transport buys us a *lot*.


More information about the Standards mailing list