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

Kim Alvefur zash at zash.se
Wed Feb 15 10:54:26 UTC 2017

On Sat, Jan 28, 2017 at 05:26:00PM +0000, XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0368 (SRV records for XMPP over TLS).
> Abstract: This specification defines a procedure to look up
> xmpps-client/xmpps-server SRV records (for TLS connections) in
> addition to xmpp-client/xmpp-server and mix weights/priorities.
> URL: http://xmpp.org/extensions/xep-0368.html
> This Last Call begins today and shall end at the close of business on
> 2017-02-11.

Better late than never?

TL;DR: XEP is okay, but for different reasons than stated.

Bypassing restrictive firewalls seems like an odd use case to base a
specification on. The merits of re-using tools developed for other
Direct TLS protocols should be enough.

I believe others has covered the accuracy and general layout of the

I would note that there is a precedent for the method of looking up
multiple different SRV records in [RFC6186].

The problem of restrictive firewalls that block everything but TLS on
port 443 isn't a technical problem and attempting to solve it via
technical means is not going to do much but further an arms race. I
don't think we should take part in such an arms race.

There's also something of a circular logic in putting all services on
the same port because other ports are blocked, and all those other ports
are blocked because all services are on the same port. This is why we
can't have nice things like SCTP or other alternatives to UDP and TCP,
since those inevitable get dropped by middleboxes and firewalls. I
really don't like the outlook of the same happening on the next layer
and everything becoming forced to be HTTPS over port 443.

It's also a bit weird to go from multiplexing services based on a 16 bit
integer usually handled by the kernel, to not one but two variable
length strings, handled by a TLS stack.

I do not have any plans to implement the XEP at this time, beyond what
already exists to support the old practice of SSL on port 5223. As for
implementing the active parts for outgoing s2s connections, perhaps
after SNI support has landed, which until now has been mostly
unnecessary for an XMPP server to have.

As for security, I'm concerned that the added complexity of mixing
STARTTLS and Direct TLS will lead to security problems. Doing it one way
or the other has, as have been noted before, mostly equivalent security
properties, but doing both seems to me like it gives us the most
complexity. Making security related code more complicated for what
amounts to an optimization does not strike me as the best idea.

[RFC6186]: https://tools.ietf.org/html/rfc6186

Kim "Zash" Alvefur
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170215/925248e4/attachment.sig>

More information about the Standards mailing list