[Standards] XTLS revisited
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
> setup similar to client/server communication: one roundtrip Jingle,
> 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.
> 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
> 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:
<-> TLS negotiate over IBB-a-like
<-> 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
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards