[Security] XTLS

[Mridul]

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) : take 
stream of bytes from ibb xtls, construct packets out of it, associate it 
with underlying xmpp stream and use it : reverse for writes.
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