[Standards] XTLS revisited

Dirk Meyer dmeyer at tzi.de
Tue Dec 16 11:17:55 UTC 2008


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='kingclaudius at shakespeare.lit/castle'
|     id='jingle1'
|     to='laertes at shakespeare.lit/castle'
|     type='set'>
|   <jingle xmlns='urn:xmpp:jingle:0'
|           action='session-initiate'
|           initiator='kingclaudius at shakespeare.lit/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='laertes at shakespeare.lit/castle'
|     id='accept1'
|     to='kingclaudius at shakespeare.lit/castle'
|     type='set'>
|   <jingle xmlns='urn:xmpp:jingle:0'
|           action='session-accept'
|           initiator='kingclaudius at shakespeare.lit/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='kingclaudius at shakespeare.lit/castle'
|     id='info1'
|     to='laertes at shakespeare.lit/castle'
|     type='set'>
|   <jingle xmlns='urn:xmpp:jingle:0'
|           action='session-info'
|           initiator='kingclaudius at shakespeare.lit/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!



More information about the Standards mailing list