[Standards] Proposed XMPP Extension: XMPP Transport Layer Security

Peter Saint-Andre stpeter at stpeter.im
Thu Nov 1 21:49:13 UTC 2007


Justin Karneges wrote:
> 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*.

Well this gets back to what Tomasz said: why not have an opaque data
transport? Whether you use it for XTLS or anything else is up to you.

/me ponders

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20071101/58c7279b/attachment.bin>


More information about the Standards mailing list