[Standards] Proposed XMPP Extension: SRV records for XMPP over TLS
travis at burtrum.org
Wed Dec 9 17:50:21 UTC 2015
On 12/09/2015 05:58 AM, Dave Cridland wrote:
> - The SRV label form probably ought to follow the precedent set by RFC
> 6186, even though I think that's uglier.
I am fine with changing the SRV format from the current
_xmpps-client._tcp/_xmpps-server._tcp instead. That a single one is
chosen is really all that matters, we don't want a SIP scenario where
_sips._tcp is in the standard yet most clients look for _sip._tls so in
practice both have to be set...
I'm not sure if it's appropriate to mention in this XEP, but I'd prefer
it be explicit somewhere that SSL is not acceptable, only TLS is, and
*preferably* TLSv1.2+? _tls kind of implied that, xmpps doesn't seem as
strong to me.
> - I'm not at all convinced by abusing SNI in lieu of ALPN.
I'm also fine with using the domain-portion of the JID for the SNI name
as well, in which case SNI is used solely to choose a certificate and
ALPN is used solely to multiplex based on protocol, as they were designed.
What this does, however, is effectively prevents multiplexing in the
near future until ALPN has more widespread client support (which http2
will ensure happens more rapidly than usual). Also, while applications
exist for the server to multiplex based on SNI name (sslh, haproxy,
sni-proxy, stunnel), I know of none that currently support multiplexing
based on ALPN (though I'll eventually create and submit a patch to sslh
which supports it).
Therefore, I suppose this XEP should at least note that a server
operator should not expect multiplexing to work in all scenarios and
should provide additional SRV record(s) that do not require
multiplexing? (either standard STARTTLS or dedicated XMPP-over-TLS)
If those proposals sound fine to everyone I'll submit a pull request
with those changes shortly. I'll wait a bit for some feedback before
More information about the Standards