On 27 September 2017 at 02:37, Travis Burtrum <tra...@burtrum.org> wrote: > On 09/25/2017 06:57 AM, Dave Cridland wrote: >> On 25 September 2017 at 06:06, Travis Burtrum <tra...@burtrum.org> wrote: >>> >>> Conversations has had support since before this became a XEP actually. >>> >>> Everyone I know of has implemented the server-side of the c2s connection >>> either with a dedicated xmpp-over-TLS port, or using sslh to multiplex >>> on ALPN. Debian even has an (unfortunately-named) section of their wiki >>> on installing prosody about it [1]. >>> >>> I also count 21 public servers on this test chart that have support [2]. >>> >> >> Do those all support SNI? I think SNI is critically important here >> (and it's a MUST in the specification). > > I'm not sure exactly which you are asking questions about, so I'll just > mention them all. >
Thanks for this information. For the record, I'd love this XEP to advance, I'm just trying to ascertain whether it can, and would much rather apply a strict interpretation of the rules. The rules on "two implementations" are, I believe, aimed to correspond to RFC 2026's Section 4.1.2, with the addition of licensing requirements. I'd note, in particular, the second paragraph: The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. This does not have procedural force in the XSF, however I think it's a sensible consideration - it makes little sense to include options not exercised. > 1. Yes Conversations supports SNI[1] and ALPN[2] where available. These > are guaranteed to be in android 4.2 and 4.4 respectively, and *might* be > supported earlier depending on vendor. According to the stats[3] this > means ~92% of androids currently in use support both. > FWIW, XEP-0001 talks about implementations, rather than deployment, but this information is nevertheless useful, thanks. > 2. SSLH will multiplex on both ALPN and SNI, prosody doesn't support SNI > on it's 'legacy_ssl_ports' (name needs changed...), though there was an > unfinished patch floating around. > > 3. My guess is most of those host a single domain and don't need SNI. It's not clear to me whether SSLH really counts as an implementation, and your (3) suggests that you really consider SNI a "SHOULD" or possibly "MAY" for servers. This may be a reasonable stance, given that for a single domain C2S it isn't required. The strict interpretation is really on the number of distinct certificates rather than the number of distinct domains, so one could apply the same argument to S2S. So we end up with: * ALPN seems to be a MAY for servers, and at most a SHOULD for clients (but probably a MAY). * SNI is a MUST for clients but a SHOULD for servers, noting that multiple certificates will necessitate SNI to be properly interoperable. * With these changes, anything supporting "legacy SSL", or "xmpps", is conformant on the server side for C2S - but none of these support SNI or ALPN. * We have one client implementation, supporting SNI and ALPN. * We have one S2S implementation, supporting SNI. On that basis, I don't *think* we can include S2S in Final, which is frustrating. We probably can include C2S, but with only one client-side implementation it's playing a little fast and loose, I think, and I'd much rather see SNI support server-side to feel satisfied that SNI is actually covered. I'm therefore leaning toward gently pushing back on this (though I suspect I might find the time to implement in Openfire). Dave. > > [1]: > https://github.com/siacs/Conversations/blob/master/src/main/java/eu/siacs/conversations/utils/SSLSocketHelper.java#L33 > [2]: > https://github.com/siacs/Conversations/blob/master/src/main/java/eu/siacs/conversations/utils/SSLSocketHelper.java#L45 > [3]: https://developer.android.com/about/dashboards/index.html > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
