[Security] XTLS

[Mridul]

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
>