Justin Karneges wrote:
based on our requirements, we could simply re-use TLS semantics in XMPP syntax rather than define a completely new security protocolThis 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! :) /psa
smime.p7s
Description: S/MIME Cryptographic Signature
