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 specification. 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
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
