Justin Karneges wrote: > 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.
Too bad I read this now that I just updated the xtls document. :( So you suggest to handle xtls just like an in-band bytestream with a tls layer on top of it? So unlike the current document you propose that every time your tls lib sends something to a socket you put that into a xmtls iq and send it away? Also for the handshake? I like the way the handshake is now with all messages in one iq stanza. But you are right, for application data it would be easier to send what we get from the tls lib used. So one <message> could result in more than one xtls <iq>. Maybe keep the handshake as it is and just re-define application layer data? Or everything as stream? I looked at the tls implementation I use and keeping the handshake as it is seems to be very easy. > DTLS would not have this problem as much, since it is designed as packetized, > but most people don't have access to DTLS implementations. I think that is a big no-go. >> 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. Well, we could handle xtls just like a special form of an IBB without the extra IBB layer, just starting <xtls> and handle it as a bytestream. > 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. It would be cool to negotiate extra stream parameter for IBB. Besides TLS stream compresion comes to my mind. | <iq type='set' | from='[EMAIL PROTECTED]/orchard' | to='[EMAIL PROTECTED]/balcony' | id='inband_1'> | <open sid='mySID' | block-size='4096' | xmlns='http://jabber.org/protocol/ibb'> | <feature>urn:xmpp:tmp:tls</feature> | <feature>urn:xmpp:tmp:gzip</feature> | </open> | </iq> | | <iq type='result' | from='[EMAIL PROTECTED]/balcony' | to='[EMAIL PROTECTED]/orchard' | id='inband_1'> | <feature>urn:xmpp:tmp:tls</feature> | </iq> In this example Romeo wants tls and gzip compression and Julia answers with tls (because she can't do compression). Now the implementation knows to start the tls handshake. XTLS should define (like it does now) to remove the routing information since we don't need it. Or (to make it simpler and not support compression) XTLS could define that the IBB sid urn:xmpp:tmp:tls means to open an IBB with TLS for client to client stanza exchange. Many ideas, what do you prefer? >> extra stream advantages: > [...] >> 2. Reuse code used for link-local messaging > > I think this is a really cool idea. For entities in the same LAN link-local messaging is the easiest way for client to client communication. See Sections 6.1 and 6.3 in http://www.tzi.de/~dmeyer/media-network.html Dirk -- Hard work never killed anyone, but why give it a chance?
