[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 mailing list