Peter Saint-Andre wrote: > Greg Hudson wrote: >> On Tue, 2008-08-19 at 21:56 -0600, Peter Saint-Andre wrote: >>> It does? Negotiate a reliable transport, start an XML stream, and >>> upgrade the stream to encrypted via STARTTLS, just like we >>> currently do for client-to-server streams. How is that enormously >>> complex? Granted, the reliable transport might not be raw TCP -- it >>> might be a direct or mediated bytestream (XEP-0065), an in-band >>> bytestream (XEP-0047), or some other reliable transport. But I >>> don't see how that makes the complexity enormous. >> >> If existing TLS libraries can be used for XTLS, then my argument >> collapses, since those same libraries are already used for channel >> security. I'm skeptical that it will work; perhaps a proof of concept >> is in order. > > I'm all for that. Unfortunately I'm just about the worst coder in the > XMPP community, so I need to defer to others. I think Dirk Meyer has > been working on this, but I'm not sure how far he's gotten.
Yes, I have some python code doing this. It is not public yet because it needs some cleanup and some more docs. If you want I can upload a tgz somewhere. It works very well. About in-band bytestreams: I just connect the IBB with a unix domain socket. So the TLS lib reads from a socket like it is used to be. The difference here is only that the implementation must perform different validations (that part is what the discussion is about) and that the stream must be connected to one remote client. And the client needs to support some server code like being the server and answering a <stream> request. But the later is similar to link-local messaging. So my implementation simply connects the IBB with a unix domain socket and after that the link-local part takes over. A client supporting link-local messaging does not need much updates. Dirk P.S.: 21 Mails over night, not bad :) -- In the beginning was the word, and the word was content-type: text/plain
