-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/09/2015 06:20 PM, Tomasz Sterna wrote:
> Dnia 2015-11-09, pon o godzinie 17:33 -0500, Travis Burtrum pisze:
>> That seems like a ridiculous question to me.  If not, why even bother
>> with STARTTLS/TLS in the first place?  It *could* be used for
>> circumventing security policies after all.
>
> Your own words from the XEP:
> "at least equal and perhaps increased security and privacy over using
> STARTTLS. It also provides an easy way for clients to bypass
> restrictive firewalls that only allow HTTPS, and for servers to host
> multiple protocols/services on a single port"
>
> I'm pointing that:
> - designing to bypass security policies may not be a well received
> reasoning

That's just one example usage, both BOSH and XMPP-over-Websockets can
also be used the same way as they are also indistinguishable from
http-over-tls, yet they are approved XEPs.  You can't design new
features worrying about whether they might violate some administrator's
arbitrary rules, they almost certainly will, but that's the user's
problem.  Many administrators/companies have rules against chatting all
together, yet XMPP exists.

> - hosting multiple protocols on a single port is a job of protocol
> level multiplexer - standard _tcp records are just fine here

Multiplexing by sniffing the first few bytes of network traffic is
unreliable, a total hack, and completely impossible for some protocols
in which the server must speak first (like SMTP).  Where as using SNI is
foolproof, ALPN was actually built for this explicit purpose, and both
work regardless of the underlying protocol every time.

> - if your admin wants to block you on protocol level (not simple port
> blocking), it is just as "trivial" to target DNS, ALPN etc. as to
> target XMPP protocol blocking

There are as many ways to block internet access as there are ways around
those blocks, this proposal doesn't claim to be a solution for every
type of block, or really even any, it's simply another method of
discovering XMPP servers that both servers and clients must agree on
before use.

> Could you elaborate how TLS instead of STARTTLS may perhaps increase
> security, as this is not clear to me?

TLS can be more secure than STARTTLS because it isn't susceptible to
STARTTLS stripping[1], which actually happens on real ISPs. And it's
more private because it blends into all the other TLS protected traffic,
rather than announcing I'M CHATTING OVER XMPP to everyone who can listen.

In fact, STARTTLS's only purpose is so you can accept encrypted and
plain-text traffic on the same port, which is pretty useless considering
it's universally accepted now that XMPP should only ever operate over
encryption, right?  If the XMPP Core RFC was written today, does anyone
doubt it wouldn't just operate over TLS exclusively?  XMPP has never
been a protocol to stand still, and I hope this proposal is yet another
small way to move it forward.

[1] https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlZBVpIACgkQF11X3nXPI/7FAACeK/Y8zK17zCpXY1x+2cSyk4Xj
SpsAniXof7I5sHPnay5N7WTaYgjQ1QDB
=peiu
-----END PGP SIGNATURE-----


Reply via email to