[Security] Re: e2e feedback
stpeter at jabber.org
Tue Mar 13 16:32:03 CDT 2007
Justin Karneges wrote:
>> based on our requirements, we could simply re-use TLS semantics in XMPP
>> syntax rather than define a completely new security protocol
> This is not such a bad idea. A good example of an adapted TLS already in
> existence is DTLS (RFC 4347). DTLS re-uses just about everything it can from
> TLS, to provide security over an unreliable packetized session.
Right. I was not creative enough to think of "XTLS" because I always
thought that TLS was for transport layers like TCP and (with the DTLS
modifications) UDP. We talk about XMPP as a transport technology, but
it's at a different layer in the stack than TCP or UDP.
> The basic
> difference from normal TLS is that packets may be dropped or be received out
> of order, and that there is a limitation in the maximum size of a payload
> (basically all UDP limitations, but beware of the security implications that
> come along with them).
> Just to get the mind churning, we could use unmodified DTLS over XMPP quite
> easily. Just base64 encode DTLS packets, and ship them off.
> However, XMPP doesn't suffer from as many limitations as UDP. We have no hard
> limit on stanza size, and packets are not delivered out of order. Thus, we
> may want to find middleground between DTLS and TLS.
That seems to be the best way.
> Or... maybe TLS is enough? We could establish a new <stream:stream> between
> client endpoints, over IBB, protected with TLS.
Yes, or that. And finally a use for IBB! :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20070313/e9f12cd2/smime-0001.bin
More information about the Security