On Fri, Nov 09, 2018 at 05:16:42AM +0700, Ted Lemon wrote: > On Fri, Nov 9, 2018 at 3:15 AM Dave Cridland <dave@xxxxxxxxxxxx> wrote: > > The consumer market is dominated by a set of large, well-funded companies > > with a vested interest in ensuring there is no standard. > > Perhaps this is true, but that's not why XMPP failed. XMPP failed because > it's really difficult to set up, even if you already have a client. And > that in turn makes it hard to set up clients. If I want to join an IETF > jabber room, I first need to set up a jabber account somewhere, and that > jabber account has to have federation working so that I can connect to the > IETF's jabber setup. > > If we wanted jabber to actually work, we would get rid of the federation > requirement, which is totally superfluous for the case of participating in > the IETF. In an IPv6 end-to-end network, federation for messaging doesn't > really add value—it's just a barrier to entry. Maybe it made sense in the > land of NAT, but at this point I think we are more likely to have working > IPv6 than to have working Jabber. Good points. The IETF could, of course, just provide accounts in an ietf-participants.org domain. I could understand if it was reluctant to do so perhaps even with a separate domain for participants. Allow me to sketch wildly about federation for a moment. I know, it's not the place to do it. But if federation was the issue (and I agree that it was), then how about... using DANE for federation? Then all one has to do to federate is sign their zone and publish TLSA RRs for their issuer. Sketch #1: - use TLS with user certs (I know! bear with me) - with a client-side extension to carry the user certificate's *issuer*'s DANE DNSSEC chain - and with only rfc822Name SANs whose domainname is the issuer's from its TLSA RRset domainname (or xmppName, if we add such a SAN) (by using only SANs with a domainname component we can make DAN work for authenticating issuers implicitly constrained to those domains) User certs in TLS just don't work because we can't use the WebPKI there, but using DANE would get us down to a one-root PKI (DNSSEC). As it happens the DNSSEC PK is already used in email, and XMPP handles look enough like email addresses that they might as well be (or we could add a SAN for them). User certs in TLS don't work also due to UI issues. Those are much more tractable than the XMPP account and federation setup, but still, that brings me to the next sketch. Sketch #2: - use SASL/GSS-API, perhaps via HTTP/Negotiate - with a TLS-based mechanism (like GSI's) - and user certs The second one is a lot like the first in that user certs are involved, but, unlike the first case, browsers today *do* have HTTP/Negotiate support, and SASL libraries typically support GSS mechanisms, and the UI issues can be factored out of the browsers/apps. The only thing missing is a GSS mechanism that internally uses TLS, but in fact there is such a thing[0]! Granted, the GSI mechanism[0] is non-standard, and could probably use a lot of help besides standardization. And standardization will be somewhat tricky. FYI, the GSI mechanism is a lot like SChannel, where SChannel is an SSPI interface to TLS and the GSI mechanism is a GSS-API interface to TLS. [0] https://github.com/globus/globus-toolkit/tree/globus_6_branch/gsi/gssapi/source Nico --
