Message got posted before I could edit it, apologies.
Mridul wrote:
Thinking more, we are going to end up with one xmpp client stream impl
riding on top of another (kind of link inband link local streams) :
(kind of link inband link local streams) -> (kind of like inband link
local streams)
take stream of bytes from ibb xtls, construct packets out of it, associate it
with underlying xmpp stream and use it : reverse for writes.
packets -> stanza's, jso calls it packets, and this escapes into my
conversations :-)
Regards,
Mridul
This would require some jugglery on part of the clients, though
definitely no something which cant be done.
Mridul
Justin Karneges wrote:
On Wednesday 21 March 2007 9:34 am, Peter Saint-Andre wrote:
Justin Karneges wrote:
On Friday 16 March 2007 8:17 pm, Peter Saint-Andre wrote:
Justin Karneges wrote:
If by XTLS you mean you want to define a usage of TLS (e.g. base64
encoding segments of a TLS stream), then that shouldn't be scary at
all.
Sure we'd have things like:
<iq>
<xtls xmlns='urn:xmpp:xtls'>base64</xtls>
</iq>
The TLS stuff would all be base64-encoded, just hand it off to OpenSSL
and you're done. Sort of. :) We'd need to bubble the results up to the
XMPP application layer so the client knows when the negotiation is
done.
And I'm sure there are subtleties. But that is the basic idea AFAICS.
I think you're done. :) Running TLS over an IBB (or similar) stream is
not any different from running TLS over TCP, provided you don't have to
fight your TLS library very much. The client knows when the TLS
negotiation is completed because the TLS library says so.
I don't know if we need IBB for that, why not put it in a dedicated
namespace? IBB is general, xtls is more specific.
TLS protects a bytestream of data. We haven't defined what would be
inside of this stream, but anyway this stream needs to be transported
over XMPP as a series of stanzas. I only suggest IBB as the transport
because you'll end up reinventing it anyway. E.g. the difference
wouldn't amount to much more than changing the element & namespace.
If we went this route, I'd suggest simply starting an XML stream
over the
TLS channel, and using that for stanza exchange. Voila, e2e.
What exactly is the TLS channel? My understanding is that you'd exchange
these <message><xtls>base64</xtls></message> stanzas to do the
negotiation and then you'd have a TLS channel over XMPP, so all your
comms with the other person would now be included in those <xtls/>
elements. But probably I'm missing something -- would we use <xtls/>
only for the negotiation? If so, then what?
We'd use <xtls/> elements the whole time, for negotiation and after.
However, the important thing to keep in mind is that the application
generally doesn't (and isn't supposed to) know what are in these
packets. A piece of TLS stream data could include negotiation bits, a
partial stanza, several stanzas, etc. The application doesn't care
what the contents are; the results are simply fed into a TLS library.
It is the TLS library that says to the application, "the negotiation
finished", or "here is some nice decoded data". The abstraction is
similar to TCP: the application isn't supposed care how the underlying
transmission actually packetizes, the application simply knows that it
has a bytestream to operate on.
As noted above, we still have to define what should go into the
bytestream. I suggest a c2s-like session. This would be similar in
usage to the legacy 5223 SSL, where a stream is established with the
other party (via IBB), TLS is immediately negotiated, and then you
open a <stream> and start sending stanzas.
<stream:stream ...>
<message> .... </message>
<message> .... </message>
</stream>
No authentication would be needed (akin to link-local).
-Justin
