[Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

Travis Burtrum travis at burtrum.org
Tue Feb 14 14:25:17 UTC 2017

On 02/13/2017 04:43 PM, Ruslan N. Marchenko wrote:
> Yes, and that's what written as XEP's use-case - how to abuse corporate
> firewall by masking im/p2p software to legitimate business traffic (https).
> This is not fair, and if I were CSO who found out such "use-case" in the
> network I'd just ordered to block pass-through TLS pushing people to use
> either explicit or implicit (transparent) proxy.

I wouldn't say it's purpose is to abuse corporate firewalls, maybe it
has a side-effect of doing that, but as you say if they (controlling all
devices) actually want to have control over what goes on inside a TLS
stream, they can by installing a CA and mitm'ing all traffic.

It's basically got 3 maybe 4 use cases, share ports with other TLS
services, enable connectivity from places with dumb firewall policies
(airports, coffee shops etc), save roundtrips.  And this is the maybe,
most TLS libs I've seen it's easier to establish a direct TLS connection
than xmpp's custom STARTTLS.

> With all due respect and honesty I thought times when there was separate
> port for encrypted/non-encrypted traffic are passed by replaced by
> start-tls concept.
> <required/> starttls feature is quite transparent and flexible, if
> someone strips it - server just refuses progressing the handshake.
> I don't understand what do we need to hide here by summoning port 5223
> from the oblivion.

STARTTLS was a good idea when it was still acceptable to have both
unencrypted and encrypted connections, because port sharing is good? :)
It's no longer acceptable to have unencrypted connections which makes
STARTTLS quite useless, and TLS and ALPN allow us to not only port share
with other XMPP ports, but with any TLS port, port sharing is good right?

More information about the Standards mailing list