[Standards] Proposed XMPP Extension: XMPP Transport Layer Security
Justin Karneges
justin-keyword-jabber.093179 at affinix.com
Thu Nov 1 16:41:47 CDT 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*.
-Justin
More information about the Standards
mailing list