Dirk Meyer wrote:
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 atgz somewhere. It works very well.
That's great!
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.
I mostly agree. I think the main challenge for existing codebases will be to abstract out the stream handling. Right now stream handling is probably tied to TCP in a lot of clients, but on this model stream handling needs to be a bit more abstract so that it can be used for c2s TCP (and HTTP), link-local, and e2e via in-band bytestreams or some other reliable transport.
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
