[Security] XTLS

[Justin Karneges]

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