[Security] Re: e2e feedback

[Peter Saint-Andre]

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! :)

/psa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20070313/e9f12cd2/smime-0001.bin