On 06/05/2008 3:44 AM, Dirk Meyer wrote: > 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.
I think we'd allow you to batch the TLS messages together into one IQ if desired -- a kind of pipelining, I suppose. > 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>. Right. > 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. I think Justin's idea was that we have IBB, so why not use it? Just trigger the special XTLS usage of IBB with an initial IQ in a different namespace. >> 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. Won't the compression be automatically set up during TLS negotiation if both sides support 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? I don't like the idea of hardcoding the SID, that feels like a hack. >>> 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 Agreed. We've never defined the link-local encryption very well, but IMHO it would use standard XMPP stream semantics. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
