On 06/13/2008 1:10 PM, Peter Saint-Andre wrote: > On 06/09/2008 11:09 AM, Peter Saint-Andre wrote: >> On 06/09/2008 9:50 AM, Dave Cridland wrote: >> >>> However, I got talking to Rob McQueen - there's a certain amount of >>> sense in, instead of describing this in terms of IBB, describing it in >>> terms of Jingle. >>> >>> It's possible - and reasonable - to consider an XMPP stream as content, >>> in which case the TLS becomes a transport (or possibly attribute of the >>> transport). >> Part of the idea behind XTLS is that you might want to use the XTLS >> "tunnel" for all e2e communications with another party. In particular, >> you might want to use that tunnel so that you don't expose your IP >> addresses during a Jingle negotiation (e.g., if you did XTLS over >> ICE-TCP or SOCKS5). So forcing XTLS to depend on Jingle might defeat the >> purpose. What transport would be used if we described XTLS in terms of >> Jingle, and might you expose personally identifying information in that way? > > I just had a chat with Justin Karneges about XTLS. I'm now convinced > that it's best to follow the approach outlined above -- use Jingle to > negotiate an e2e stream that is transported via a reliable transport > mechanism such as SOCKS5 Bytestreams, IBB, reliable UDP, or whatever > else people come up with. I am currently revising the proposal along > those lines and will post to the list when I'm finished with the edits.
OK, while working on this I realized that the most modular way to spec this out is as follows: 1. We modify XEP-0174 so it just defines _presence._tcp as a discovery mechanism, as a result of which you have an IP address and port that you can use for a direct TCP connection that functions as a transport for an e2e XML stream. 2. We split the e2e XML streams stuff out from XEP-0174 into a new "e2e-streams" spec, which defines how you use whatever reliable transport is close to hand (direct TCP connection, IBB, SOCKS5, ice-tcp, etc.) as the transport for an e2e XML stream (this can be unencrypted as all XEP-0174 implementations do now, or upgraded to encrypted using STARTTLS, which is what we'd recommend -- but this way it is backwards-compatible and enables code reuse). 3. The current XTLS spec morphs into a new "Jingle-xmpp" spec that defines a Jingle application type for an XMPP session (as defined in XEP-streams), where that application type can use IBB, SOCKS5, ice-tcp, or any other reliable transport. So this is the way I'll proceed. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
