[Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)
Ruslan N. Marchenko
me at ruff.mobi
Tue Feb 14 19:00:41 UTC 2017
On 14.02.2017 15:25, Travis Burtrum wrote:
> (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.
Maybe it's because I'm not using high-level abstraction libs but with
openssl the process is identical, unless you want to fall back to
meaningless insecure defaults with wrappers.
> 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?
It has nothing to do with port reuse, rather service binding. When I'm
thinking how many ports I need to open on firewall to allow simple mail
exchange - it just makes me feel sad an sorry for all the people who
developed those standards. And all these stupid http->https redirection
could be avoided if http supported starttls and you simply enforce it on
server (upgrade required).
We have a service, service is bound to the port, service has ability to
be secure - what else do we need? We're not going to abandon
non-encrypted communication, encryption overhead simply does not make
sense in some cases. Hell there's gtalk federation (yet) :) stream
handshake already has all the necessary controls to make security
mandatory. I understand that S2S and C2S on different ports is a legacy
we can hardly get rid of it, although we've managed to get rid of port
5223 by defining the way to require starttls.
Also one security drawback here - now to DoS by encryption abuse vector
you need to negotiate stream before doing starttls - meaning you need to
have handcrafted tool just for this protocol. With TLS on socket you can
use anything which is able to open secure socket (probably related to
the quote above?).
More information about the Standards