Hi,
I'm currently implementing secure end-to-end XML streams based on
Jingle-{IBB,S5B,XTLS,XML streams} and stumbled upon some questions
regarding stanza routing.
With secure end-to-end XML streams (e.g., for the purpose of encrypted
text chat) we're moving away from clients with a single connection to
one server, to a network of interconnected entities, each acting as
client and server for end-to-end connections at the same time.
Consider Romeo and Juliet, both connected to their federated XMPP
server, negotiating a secure end-to-end XML stream. Romeo (initator)
acts as client, while Juliet (receiver) has to accept Romeo's connection
and therefore acts like a (dumb) server. They end up with two possible
'paths of communication': the old path via the servers which they used
to negotiate the XML stream, and the new path through the newly
established connection. Now, both clients have to decide for each
outgoing stanza which path to take:
Q1. Which stanzas should be sent by the client over the old
path and which stanzas over the new one?
Q2. Should a client send Initial Presence over the new path
to signal its availability for communication?
Q3. Should a client continue existing conversations over the
new path (i.e. use the same <thread/> for messages), or
start a new conversation (which usually results in a new
tab/window in most GUIs)?
Let's assume the new path replaces the old path for stanzas directed
from Romeo to the full jid of Juliet that Juliet used to negotiate the
end-to-end stream. Now, of course, it's still possible to send stanzas
to Juliet's bare jid:
Q4. Should stanzas directed to a bare jid always be sent
via the server, or should the client look at received
presence stanzas from that jid and, if the client has
a end-to-end connection with the resource of the
highest priority, send it directly over the new path?
Q5. When an end-to-end stream is closed, should a client
reject / store offline / send over the old path any
further stanza that is directed to the full jid?
It could lead to severe security issues if a user
believes that communication is still secure.
Q6. When the connection to the server is closed but an
end-to-end stream still exists, should the end-to-end
stream be closed as well? (With IBB it is, with S5B
by default it's not.)
Q7. If the stream is not closed, does the contact appear
online in the contact list or does he appear offline?
That is, does the end-to-end stream now serve as the
target for the bare jid of the contact? (What happens
to presence subscription requests?)
Q8. How are stanzas routed if there are two or more end-
to-end streams between two entities?
Q9. If only one end-to-end stream is allowed, what should
happen if a second one is negotiated (e.g., is the
old one dropped)?
I think a few questions could be anwered more easily if the new path
wasn't replacing the old one. Instead, an end-to-end stream could be
treated just like an additional resource of the peer. That is, two
resource identifiers identifying the same entity (or, more precisely,
the two paths to it). Would that make sense?
--K.
