Recently I've been chatting with some folks off-list about end-to-end encryption. I've concluded that while it is possible to set up an end-to-end XML stream (XEP-0246) using Jingle (XEP-0247) and then upgrade that stream to encrypted using STARTTLS, we don't need that complexity because you already have a reliable connection to the other person: it's called XMPP (there's nothing to negotiate here and no need for SOCKS5 Bytestreams or ICE-TCP or any of that madness, just use XMPP for the transport). Therefore I suggest that we simplify e2e by using something very close to the original XTLS proposal to set up, use, and tear down and XTLS tunnel. I've outlined the protocol below.
1. Initiator sends start request to responder <iq from='[email protected]/orchard' id='xtls_1' to='[email protected]/balcony' type='set'> <start xmlns='urn:xmpp:tmp:xtls'/> </iq> 2. Responder tells initiator to proceed <iq from='[email protected]/balcony' id='xtls_1' to='[email protected]/orchard' type='result'> <proceed xmlns='urn:xmpp:tmp:xtls'/> </iq> 3. Initiator and responder complete TLS handshake <iq from='[email protected]/orchard' id='xtls_2' to='[email protected]/chamber' type='set'> <data xmlns='urn:xmpp:tmp:xtls' method='x509'> base_64(TLS-Handshake-Messages) </data> </iq> <iq from='[email protected]/chamber' id='xtls_2' to='[email protected]/orchard' type='result'/> <iq from='[email protected]/chamber' id='xtls_3' to='[email protected]/orchard' type='set'> <data xmlns='urn:xmpp:tmp:xtls'> base_64(TLS-Server-Handshake-Messages) </data> </iq> <iq from='[email protected]/orchard' id='xtls_3' to='[email protected]/chamber' type='result'/> 4. One party sends a stanza over the tunnel 4a. Generate stanza <message from='[email protected]/orchard' to='[email protected]//chamber' type='chat'> <thread>act2scene2chat1</thread> <body> I take thee at thy word: Call me but love, and I'll be new baptized; Henceforth I never will be Romeo. </body> <active xmlns='http://jabber.org/protocol/chatstates'/> </message> 4b. Strip off the routing data <message type='chat'> <thread>act2scene2chat1</thread> <body> I take thee at thy word: Call me but love, and I'll be new baptized; Henceforth I never will be Romeo. </body> <active xmlns='http://jabber.org/protocol/chatstates'/> </message> 4c. Encrypt and base64-encode it base_64(TLS-Encrypted-Message) 4d. Send it over the tunnel <iq from='[email protected]/orchard' id='xtls_4' to='[email protected]/chamber' type='set'> <data xmlns='urn:xmpp:tmp:xtls'> base_64(TLS-Encrypted-Message) </data> </iq> <iq from='[email protected]/chamber' id='xtls_4' to='[email protected]/orchard' type='result'/> 5. One party closes the tunnel <iq from='[email protected]/orchard' id='xtls_10' to='[email protected]/balcony' type='set'> <close xmlns='urn:xmpp:tmp:xtls'/> </iq> 6. Other party acknowledges the close <iq from='[email protected]/balcony' id='xtls_0' to='[email protected]/orchard' type='result'> <closed xmlns='urn:xmpp:tmp:xtls'/> </iq> That's it! Yes, there are some slight further complexities (e.g., including "offer" information as in XEP-0250) and error flows to document, and we need to carefully define the use of X.509 certs, PGP keys, secure remote password, and other methods. But I don't think that end-to-end encryption needs to be much more complex than what I've outlined above (at least on the wire -- the complexities emerge from the user interface, cert/key management, etc.). Dirk Meyer and I are working to update the original XTLS proposal accordingly, and will have a document to share in the next day or two. Until then, our work in progress is here (we'll post again once it is more stable): http://xmpp.org/extensions/inbox/xtls.html Peter -- Peter Saint-Andre https://stpeter.im/
