Dave Cridland wrote: > Okay, so humour me for a second. Sure :)
> In practical terms, then, we move XEP-0250 negotiation inside Jingle > as a transport, and strip down IBB to remove the initial open > business (we can essentially compound that into the session-initiate). > > Furthermore, we can assume that SASL EXTERNAL is simply not required > here - because it's not, really, for many cases. > > Now, the exchange becomes: > > --> session-initiate > <-- result > <-> TLS negotiate over IBB-a-like > <-- session-accept > --> result > <-> XMPP stuff overTLS-protected IBB-a-like. I had a similar idea when writing my last mail. Let's think this further. I can add everything I want in a Jingle stanza. It would also be a good idea to have TLS for Jingle. Even if we do XTLS without Jingle, a TCP secure file transfer is also a good idea. Let's take XEP-0234: Jingle File Transfer as example: We send our TLS wish and the XEP-0250 offer in the initiate: | <iq from='[email protected]/castle' | id='jingle1' | to='[email protected]/castle' | type='set'> | <jingle xmlns='urn:xmpp:jingle:0' | action='session-initiate' | initiator='[email protected]/castle' | sid='851ba2'> | <content creator='initiator' name='a-file-offer'> | <description xmlns='urn:xmpp:jingle:apps:file-transfer:0'> | ... | </description> | <transport xmlns='urn:xmpp:jingle:transports:bytestreams:0'/> | <tls> | <offer from XEP-0250/> | </tls> | </content> | </jingle> | </iq> Now the two clients set up the stream using the defined transport and the responder accepts the session. If the responder supports Jingle TLS it has to include its offer. We now if it supports Jingle TLS using disco#query. | <iq from='[email protected]/castle' | id='accept1' | to='[email protected]/castle' | type='set'> | <jingle xmlns='urn:xmpp:jingle:0' | action='session-accept' | initiator='[email protected]/castle' | sid='851ba2'> | <content creator='initiator' name='a-file-offer'> | <description xmlns='urn:xmpp:jingle:apps:file-transfer:0'> | ... | </description> | <transport xmlns='urn:xmpp:jingle:transports:bytestreams:0'/> | </content> | <tls> | <offer from XEP-0250/> | </tls> | </jingle> | </iq> Problem: if you check prior to opening the stream if we have a common ground for TLS. If we don't, we went to all this incl. opening a stream for nothing. Now we need step three of XEP-0250. We can use Jingle info for that | <iq from='[email protected]/castle' | id='info1' | to='[email protected]/castle' | type='set'> | <jingle xmlns='urn:xmpp:jingle:0' | action='session-info' | initiator='[email protected]/castle' | sid='a73sjjvkla37jfea'> | <tls method='x509'/> | </jingle> | </iq> After that kingclaudius starts the TLS handshake. > I see this as being one RTT longer than "classic" XTLS - the > session-accept - but in practise I'm not clear that we really need to > wait for that before sending "media" in this case, since both ends > know if it's working at a fundamental level. We need to wait for the XEP-0250 counter-offer. On the other hand we can use the iq stanzas from XEP-0250 parallel while we set up the transport. > The only thing I see as potentially being problematic then for > implementors is that whilst a Jingle session is active, the session > can potentially be renegotiated - is this something that's a > candidate for being made optional? (Maybe it's really needed for VOIP > applications, but it doesn't seem a requirement for this, or file > transfer.) That is not only a problem for TLS, it is a problem for all TCP-like sessions. The normal file transfer has the same problem. Dirk -- Buy one for the price of two and get another one free!
