On 9 December 2015 at 17:50, Travis Burtrum <tra...@burtrum.org> wrote: > 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 > _xmpp-client._tls/_xmpp-server._tls to > _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 think that's out of scope. As soon as TLS 1.2 is deprecated or deemed insecure, it would send this document out of date. However the mechanism described will remain valid for all versions, so I think it would be better for this spec to remain detached. RFC 6120 already references TLS 1.2, though I'm not sure if we have anything more concrete regarding TLS protocol versions. If we were to do that, it would make sense to put it on a parallel track to this protoXEP, because we'd also want the recommendations to apply equally to conventional starttls connections. >> - 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. That sounds good to me. > 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). Understood. This spec won't gain adoption overnight, and by the time it became widespread the hack would quite likely be unnecessary. > 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) Happy to see some text proposed for this part. If it explains the specifics of what could possibly go wrong, it seems like a good thing to have documented. Regards, Matthew _______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
