Re: [Standards] end-to-end stanza routing
Am 06.03.2009 um 19:24 schrieb Dirk Meyer: Depends on the file. If I send you a small txt file with my notes, IBB is ok. If I send you a mp3 file, IBB is bad, S5B with proxy is ok. If I send you a HDTV recording, the proxy administrator will kill me if I use a proxy. So for file transfer it depends on the file. We should define some rules for that. Always using P2P for file transfers and doing fall backs depending on file size sounds like a good idea. For example, if the file is < 100 MB, fall back to proxy, if it < 10 KB, fall back to IBB. No. Klaus asked about stanzas. There is only one e2e streams for stanzas. It makes no sense to open a second one. You may open another e2e tls stream for file transfer, but that has nothing to do with the question where to route a Ah, ok, I was talking about encrypted sessions in general. Misunderstood it then that we are only talking about chat/other XML stuff sessions. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] end-to-end stanza routing
Jonathan Schleifer wrote: > Yeah, but they should not use the same transport ;). > IMO, we should standarize what types of streams are transported how. > Like E2E chat MUST be usable using IBB and MAY be possible using P2E, Agreed. IBB MUST be possible as fallback and you can try S5B if you want. > whereas file transfers MAY NOT be done using IBB and MUST be supported > at least via proxy etc. Depends on the file. If I send you a small txt file with my notes, IBB is ok. If I send you a mp3 file, IBB is bad, S5B with proxy is ok. If I send you a HDTV recording, the proxy administrator will kill me if I use a proxy. So for file transfer it depends on the file. > And then it makes perfectly sense to have more than one encrypted > channel :). No. Klaus asked about stanzas. There is only one e2e streams for stanzas. It makes no sense to open a second one. You may open another e2e tls stream for file transfer, but that has nothing to do with the question where to route a Dirk -- The light at the end of the tunnel is the headlight of an approaching train.
Re: [Standards] end-to-end stanza routing
Am 06.03.2009 um 18:07 schrieb Peter Saint-Andre: Right. But those are two different application types -- the first one is an application type of xmlstream and the second one is an application type of filetransfer. They just happen to both use the same transport (IBB), but the sessions are different. Yeah, but they should not use the same transport ;). IMO, we should standarize what types of streams are transported how. Like E2E chat MUST be usable using IBB and MAY be possible using P2E, whereas file transfers MAY NOT be done using IBB and MUST be supported at least via proxy etc. And then it makes perfectly sense to have more than one encrypted channel :). -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] end-to-end stanza routing
On 3/6/09 10:00 AM, Jonathan Schleifer wrote: > Am 05.03.2009 um 23:50 schrieb Peter Saint-Andre: > >> Right. I really don't see a need for having multiple e2e streams. > > > I do. Imagine the following situation: > > I want to chat with someone encrypteed, thus I negotiate a session. I do > that using IBB (it's the default, right? At least I think we decided on > that some while ago :)). Now I want to send that user a file. If I send > that IBB, the server administrator will propably kill me ;). So I > negotiate another session that is P2P for the file transfer and STARTTLS > that as well. Right. But those are two different application types -- the first one is an application type of xmlstream and the second one is an application type of filetransfer. They just happen to both use the same transport (IBB), but the sessions are different. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] end-to-end stanza routing
Am 05.03.2009 um 23:50 schrieb Peter Saint-Andre: Right. I really don't see a need for having multiple e2e streams. I do. Imagine the following situation: I want to chat with someone encrypteed, thus I negotiate a session. I do that using IBB (it's the default, right? At least I think we decided on that some while ago :)). Now I want to send that user a file. If I send that IBB, the server administrator will propably kill me ;). So I negotiate another session that is P2P for the file transfer and STARTTLS that as well. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] end-to-end stanza routing
On 3/5/09 5:02 PM, Klaus Hartke wrote: > Kevin Smith wrote: >> I think that you send full-jid stanzas (to the right full jid!) over >> the e2e, and anything to bare-jid, or other resources goes through the >> server. > > If the e2e path replaces the path through the server for a full jid and > that full jid has the highest priority, should a stanza to the bare jid > go through the server or over the e2e? Through the server. The sender doesn't know how the server is going to handle bare-JID stanzas (this mainly applies to message stanzas), and it's not good for the sender to second-guess the server's delivery decisions. > Assume that Romeo had a secure conversation with Juliet over an e2e. He > closed the text chat window, but the e2e is still active. Romeo double- > clicks on Juliet in his contact list, a text chat window pops up. By > default, his first will be addressed to Juliet's bare jid; Romeo is an idiot. His client needs to be smart and re-use the e2e stream. > his client will use Juliet's full jid as soon as it receives the first > reply . Now, if Juliet's resource with the highest priority > happens to be the one Romeo is having the secure e2e with, does the > first message go through the server or over the e2e? Romeo probably does > not understand why closing the chat window and immeditately re-opening > it makes the conversation insecure and expects communication to be > secure right away. Agreed. > Of course, a client could pop up a big warning that a secure e2e exists > but is not being used ;-) Nah, in that case I think it's best to keep using the e2e stream. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] end-to-end stanza routing
Kevin Smith wrote: > I think that you send full-jid stanzas (to the right full jid!) over > the e2e, and anything to bare-jid, or other resources goes through the > server. If the e2e path replaces the path through the server for a full jid and that full jid has the highest priority, should a stanza to the bare jid go through the server or over the e2e? Assume that Romeo had a secure conversation with Juliet over an e2e. He closed the text chat window, but the e2e is still active. Romeo double- clicks on Juliet in his contact list, a text chat window pops up. By default, his first will be addressed to Juliet's bare jid; his client will use Juliet's full jid as soon as it receives the first reply . Now, if Juliet's resource with the highest priority happens to be the one Romeo is having the secure e2e with, does the first message go through the server or over the e2e? Romeo probably does not understand why closing the chat window and immeditately re-opening it makes the conversation insecure and expects communication to be secure right away. Of course, a client could pop up a big warning that a secure e2e exists but is not being used ;-) --K.
Re: [Standards] end-to-end stanza routing
On Thu, Mar 5, 2009 at 5:12 PM, Klaus Hartke wrote: >> > 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). > > Right. But there are some cases in which a server handles a stanza on > behalf of a user. If you use the new path for everything (except the > control messages and stanzas directed to other full jids), you'd have to > inspect each outgoing stanza if it matches one of those cases, and if it > does, send it over the old path for the server to be able to handle it. I think that you send full-jid stanzas (to the right full jid!) over the e2e, and anything to bare-jid, or other resources goes through the server. What do you send to the bare jid that the server /doesn't/ handle for you in some way? /K
Re: [Standards] end-to-end stanza routing
On 3/5/09 3:43 PM, Marcus Lundblad wrote: > tor 2009-03-05 klockan 08:43 -0700 skrev Peter Saint-Andre: > >>> 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? > > I think this is not really useful, since if you can establish a P2P XML > stream with a given entity (using f.ex. S5B) you would probably want to > open a separate file transfer stream (not another XML stream) for the > transfer. > And if the XML stream is running over IBB, you might as well establish a > second IBB session for the file transfer. > > But maybe there could be other uses where having more than one XML > stream is useful... Right. I really don't see a need for having multiple e2e streams. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] end-to-end stanza routing
tor 2009-03-05 klockan 08:43 -0700 skrev Peter Saint-Andre: > > 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? I think this is not really useful, since if you can establish a P2P XML stream with a given entity (using f.ex. S5B) you would probably want to open a separate file transfer stream (not another XML stream) for the transfer. And if the XML stream is running over IBB, you might as well establish a second IBB session for the file transfer. But maybe there could be other uses where having more than one XML stream is useful... //Marcus
Re: [Standards] end-to-end stanza routing
Peter Saint-Andre wrote: > > 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). Right. But there are some cases in which a server handles a stanza on behalf of a user. If you use the new path for everything (except the control messages and stanzas directed to other full jids), you'd have to inspect each outgoing stanza if it matches one of those cases, and if it does, send it over the old path for the server to be able to handle it. > > 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. So, Romeo types in text chat message, hits ENTER and in the same second gets a big warning that communication is now insecure before the client was able to send the message over the secure path. Should that message be discarded/queued until a secure connection is available again? Then, which stanzas should be allowed to be sent over the unsecure path after the secure path has closed: messages no, service discovery, jingle IQs yes? Or should the message be delivered (->security problem)? Treating end-to-end streams like additional resources might help here: If the end-to-end stream is closed, the resource becomes unavailable and all stanzas directed to it are not delivered. The old path identified by a different resource identifier is used to re-establish the secure con- nection or may be used for unsecure text chat again (which due to the different resource identifiers usually takes place in a different tab/window). > > 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. Well, I don't need two end-to-end XML streams, but I have to write code that handles incoming requests for end-to-end XML streams. The question is how to behave in the case an end-to-end connection with the same full jid already exists: If I allow multiple connections, which connection should be used for which stanza? If I do not allow multiple connections, which connection wins? I, too, think that we should not forbid more than one stream but should not encourage them. The question which stanza to route over which path could be solved if each path was addressable. (If someone creates two end-to-end-streams, he obviously wants to use both.) --K.
Re: [Standards] end-to-end stanza routing
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 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-en
[Standards] end-to-end stanza routing
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 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.
