[tor-bugs] #9022 [Pluggable transport]: Create an XMPP pluggable transport

[Tor Bug Tracker & Wiki]

#9022: Create an XMPP pluggable transport
---------------------------------+------------------------------------------
 Reporter:  asn                  |          Owner:  feynman 
     Type:  task                 |         Status:  accepted
 Priority:  normal               |      Milestone:          
Component:  Pluggable transport  |        Version:          
 Keywords:                       |         Parent:          
   Points:                       |   Actualpoints:          
---------------------------------+------------------------------------------

Comment(by feynman):

 I updated the protocol spec here:
 https://raw.github.com/aeftimia/hexchat/master/doc/protocol-spec.txt

 There is still work to be done.

 JIDs are often given random strings for their so called "resources" (or if
 a resource is requested, a random string is often appended to it). To send
 an IQ, one must know the recipient's resource. This is great for security,
 but bad for this particular application. To get around this, I use a
 message (which can be sent without a resource) to send a connection
 request to a JID with an unknown resource. When the recipient responds,
 thus disclosing their resource, their full JID (including the resource) is
 added to a table that keeps track of JIDs and resources.

 The problem is if one of the computers disconnects and reconnects, they
 acquire a new resource and their is no way (currently) for the other
 computer to update its table.

 Another problem is that messages that have no resource specified can only
 be sent to people on your contact list. Thus, I may have to carry on with
 the multi-user chat scheme and devise a secure way of acquiring the
 target's resource by first sending a message to everyone in the chat room.
 The obvious way of handling this would be to use asymmetric encryption to
 send initial connection messages in an encrypted form to everyone in the
 chat room, then have the recipient decrypt it and respond via IQ.

 However, before I continue with this, I would like some feedback
 concerning the practicality of the protocol thus far. Here are some
 questions I want to consider:

 Is the protocol lacking anything that has not been mentioned?
 Is it too complicated?
 Is the program still too slow to be useful?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9022#comment:44>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online