On Wednesday 04 June 2008 9:43 am, Dirk Meyer wrote: > Peter Saint-Andre wrote: > > Well XTLS is not well-defined yet, but I will turn my attention to it > > soon. The approach of starttls and then IBB was mentioned by Justin > > Karneges here: > > > > http://mail.jabber.org/pipermail/security/2007-March/000018.html > > > > And that seems reasonable to me. > > My fault. I only took a quick look at xtls and assumed it uses DTLS > (which is scary like Justin wrote). Now that I see that xtls always > uses <iq> and is in fact "normal" tls wrapped in XML it looks good to > me.
XTLS as currently documented is not usable, in my opinion, because it doesn't treat TLS like a stream. It expects each <iq> exchange to contain specific TLS frames, which are not things applications normally know about. You'd have to write a TLS parser to inspect data from your TLS library, chop them up at TLS frame boundaries, and then wrap them correctly into <iq>. You may even have some trouble determining the content of the frames you're sending. DTLS would not have this problem as much, since it is designed as packetized, but most people don't have access to DTLS implementations. For XTLS to be usable, it would need to be adjusted to treat TLS like a stream, where the <iq>-wrapped packets may contain arbitrary data (partial TLS frames, multiple TLS frames, etc). If this is done, then we'd additionally have to define a protocol that goes over the TLS stream (such as an XML stream), since you could no longer use TLS frame boundaries to determine message boundaries. So at best, your comparison would have to be against an "adjusted" XTLS as I described above. > When thinking about IBB + new stream + starttls vs. xtls I see the > following arguments: > > xtls advantages: > > 1. xtls is faster to set up. It does not require to open an IBB, > SOCKS5 or maybe even Jingle to figure out what to use. Indeed. However, the IBB approach should only amount to one extra round trip (one iq exchange to establish the desire for an encrypted session and one iq exchange for IBB, vs just one iq exchange for XTLS), which may not be so bad. If we consider IBB to be a worthwhile approach, we could easily offer an optional optimization whereby the encrypted session and IBB stream are negotiated in a single iq round trip. > extra stream advantages: [...] > 2. Reuse code used for link-local messaging I think this is a really cool idea. -Justin
