On 3/5/09 8:07 AM, Klaus Hartke wrote: > Hi, Hallo Klaus!
> 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.
Those are excellent questions.
> 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?
I think that you would use the old path (via the servers) only for
control messages related to the new path (e.g., to terminate the e2e
session).
> Q2. Should a client send Initial Presence over the new path
> to signal its availability for communication?
I don't think that's needed.
> 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)?
I think it would be OK to use the old ThreadID, although I think a good
argument could be made to create a new ThreadID for use over the new
path. This is something we'll want to clarify in XEP-0201 (which in
general needs some attention).
> 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?
I think that if you have an e2e stream, you would prefer to use that
(it's encrypted, after all). If Juliet's presence changes (so that, for
example, a new resource comes online with a higher priority than the
resource that's involved in the e2e stream), Romeo's client would need
to figure out if that new resource is more appropriate for exchanging
messages. But this is a specialized case of what to do in such instances
now (even without an e2e stream), and we've never documented best
practices for such scenarios.
> 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.
No! If Juliet terminates the e2e stream, Romeo's client needs to pop up
a big warning that communication is now insecure and give him the option
of negotiating a new encrypted channel.
> 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.)
There is some text about this in XEP-0167, but it applies more generally
to any application type so probably we need to move it to XEP-0166. The
way I see it is this: because you have lost your control channel (the
old path via the servers), the e2e stream now perhaps needs some special
handling (e.g., there is no way to formally terminate it). However, why
not continue with that e2e session? In the case of a voice chat, the
conversation could continue even if the signalling channel goes down.
But you don't want to keep the data channel active if you don't exchange
any data over it. I'll try to find the appropriate text and update it.
> 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?)
I think that presence is still driven by what happens over the
signalling channel (client-to-server XMPP).
> Q8. How are stanzas routed if there are two or more end-
> to-end streams between two entities?
It's probably good to have only one. Why would you need two? Perhaps one
for file transfer and one for XMPP chat?
> 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 don't think we would forbid more than one stream, but I also think we
wouldn't encourage it.
> 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?
Perhaps. I'll give it a bit more thought.
Thanks!
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
