[Standards] XTLS revisited

Dave Cridland dave at cridland.net
Mon Dec 15 23:16:55 UTC 2008


On Mon Dec 15 20:18:48 2008, Dirk Meyer wrote:
> Jingle XML Streams do not only use Jingle, they also use a normal  
> stream
> setup similar to client/server communication: one roundtrip Jingle,  
> at
> least one for the transport (IBB) to open the stream. These are
> two. After that we have stream setup, STARTTLS feature negotiation,
> TLS itself (2 rt), and a stream restart. Sums up to 7. XTLS needs  
> one rt
> for itself + 2 for TLS.
> 
> 
Okay, with you now, I'd forgotten about the actual stream startup.

> No, if we would use TLS directly on Jingle it would be less.

Right, indeed.

> Not suitable for e2e XML streams. For other use cases incl. TLS over
> Jingle without the stream stuff it is simpler. BTW, adding TLS for  
> any
> Jingle stream would be also nice to have.

Okay, so humour me for a second.

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 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.

However, it does give us a place to indicate why a TLS negotiation  
failed, or was rejected, by stating <connectivity-error/>. Moreover,  
we can define useful [D]TLS extension reasons which give us the  
reason why things failed.

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.)

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list