XSF Discussion - 2018-11-11

I agree with Ge0rG. As an example we've been slowly switching domains at work for all our services. For XMPP I don't see any other alternative than breaking everybody's roster (with s2s people), because nobody supports <moved/>. So I've been delaying that task as much as possible

Another example are all the @jabber.somedomain accounts from a time when we didn't have SRV records to make JID = email possible.

I'm happy to do whatever it takes to make moved work

moved <3

But I don't have much bandwidth to think about it, so file bug reports

Moved is a huge mess.

ge0rg: people added jabber. subdomains even after srv was well supported for s2s (iirc it was back in 2004/2005 even). The rationale must have been something like "jabber.ccc.de does it, they know what they are doing"

fippo: that, or lack of knowledge of SRV ✏

or lack of understanding

i would not rule out "openfire installer suggested it" either

but that was later... i think it only added s2s in... 2006?

BTW, even with the knowledge of SRV, there are many situations where it fails and clients have to fall back to A/AAAA

And even with SRV, https://github.com/letsencrypt/boulder/issues/1309 :(

Should maybe go look at what the ACME WG is doing.

https://tools.ietf.org/html/draft-ietf-acme-email-tls-05

Zash, that acme email draft, is it just a new challenge method? Not sure I understand

If so, meh. It's good that they have interest in other protocols, but I'm less worried about challenge methods

pep.: yes. one that looks fairly generic and will likely become a SRV thing at some point, but maybe some of us should go prod that so it moves along

Yeah, their dns thing looks pretty much like SRV

But as I said, I don't really care about a new challenge method for now. I'd prefer to have them issue <protocol>-only certs :x

pep.: Might be easier to argue for that if there's protocol specific challenges