XSF Discussion - 2019-12-06

Thanks for the meeting/minutes. As I mentioned on the non-public board list, I was at the protests in france :)

:)

Movim 0.16.1 released https://nl.movim.eu/?node/pubsub.movim.eu/Movim/cdfc0a4c-3459-4d3b-8c15-08994810d54e

congrats!

out of personal interest: does that now work with the latest Openfire? iirc, we've fixed the issues that caused interop problems

Do we have all the server devs in one of the channelrooMUCs?

Guus didn't tried with Openfire recently

Zash this one? 🙂

jdev?

Guus, Holger, other server devs: We Prosody devs have been thinking about phasing out Dialback, for reasons written down in https://issues.prosody.im/1471 Thoughts?

(Metarelated: We need that Hats XEP implemented)

I was going to show you how bad of an idea of that was, because over half of my s2s connections use dialback - only to find out that hardly any do.

Still, I'd not be a fan, as it'd break backwards compatibility. I'm constantly talking to people that are running server versions that are pretty old.

(even those _could_ also do certificate based auth, etc, etc)

I was going to ask why the only Dialback connections I have are to jabber.org, dwd and an openfire

Why is Openfire's (I'm assuming xmpp.igniterealtime.org) using Dialback? It has valid certs.

Why is it not offering me SASL EXTERNAL? I have valid certs?

we're running something alpha - buggydibugbug?

also, we're currently rewriting all of the s2s code...

(not doing dialback would actually save us a lot of time...)

In theory having multiplexing would be very nice, but in practice I've never seen that be used, except for that one time dwd tried and found a bug in Prosody.

So I've been leaning towards depoying XEP-0288 - Bidi instead and being happy enough with that.

> I'd not be a fan, as it'd break backwards compatibility. Same here.

I think Tigase still doesn't support SASL EXTERNAL at all, for example. (Not entirely sure though.)

Are any of the Tigase folks here or in jdev@?

fun question: those hosts which can only do dialback, what TLS version can they do?

is it likely that they will become unreachable "soon" either way because libssl drops support for that version?

I don't think we should remove support for people that for one reason or another don't want or can't set up certificates. Dialback offers better security than no security.

I can think of deployments that are deliberately not internet-facing, or have other reasons to not want to depend on Let's Encrypt

Also, everyone having valid certificates very much is an effect of one single organisation providing a service, I think. What happens if, for whatever reason, Let's Encrypt stops doing their thing (or stops being trustworthy)?

Their certificates are only valid for 3 months - having dialback as a fallback to a service that pretty much hinges on one organisation isn't the worst of ideas, maybe.

I'm not a fan of this single point of failure either

However it is the current reality

would making it easier to disable dialback be a compromise to be considered?

I did word it as "phase out", meaning not instant.

security-minded setups can then disable it, while others might opt to choose interop over security. It boils down to that question, right?

Yeah

FWIW it's pretty easy in Prosody already, just comment out that module.

Sure, not saying it wasn't 🙂

No idea about other servers, but if it's not easy then making it easy seems like a good idea.

Having given this 5 minutes of thought, I'd not be a fan of phase out Dialback though.

> Guus, Holger, other server devs: We Prosody devs have been thinking about phasing out Dialback, for reasons written down in https://issues.prosody.im/1471 > Thoughts? > (Metarelated: We need that Hats XEP implemented) Agreed with Guus phasing out DB is a horrible idea, I already more than once expressed my opinion on it

I think it's good to discuss these things though. Thanks!

Maranda : I never said it was a horrible idea.

Zash: Didn't you recently talk about disabling dialback in prosody?

Plenty of cisco jabber deployments only do DB for example

!XSF_Martin: Yes.

And not sasl external

> Same here. > I think Tigase still doesn't support SASL EXTERNAL at all, for example. (Not entirely sure though.) I'm not sure if it doesnt support it for sure I never seen any deployment I know of using it with my server

fwiw: https://issues.igniterealtime.org/browse/OF-1940

Also I never agreed about most of the security concerns on DB nowadays, very few implementations don't do STARTTLS before DB (Metronome does bump servers that do that for example)

And the rogue issuing of certificates by LE just introduces more security concerns, so I'm not sure what you expect to achieve here beside breaking interoperability

Backwards compatibility: meh Let's Encrypt: it's still not the world's only CA by far Closed setups: don't care about s2s, or can run their own CA or enable dialback

Where is memberbot again?

The source code I mean

I finally want to do a lower case and a trim around the response parsing

The fact that it doesn't accept 'Yes ' is super annoying

MattJ: I'm not the one who mentioned LE as solution for a free certificate to feed to SASL external to begin with

@Maranda - we added it recently in development versions so it will be included in next 8.1.0

Daniel, https://github.com/legastero/memberbot

See also some fixes here already: https://github.com/linkmauve/memberbot/commits/master

pep.: thank you

Daniel I think Alex mentioned forking that into the xsf github account recently. Not sure if he's working on it.

and yes, it's annoying. I'd welcome that fix 🙂

travelling right now with bad internet access. Feel free to fork it to the XSF repo and I will take it from there ;-)

I think I'll pr link's repo

also, don't think I have permissions to fork it to XSF repo, so someone else would need to do the initial fork

Maybe I can, now

https://palaver.im:5443/upload/5bb502b7c5289e610734e07c6a499759f520bf98/KfbREEd9IVGxE7vRIIZGilr520dOqpVw0Hncz4qm/2019-12-06_12_48_34-legastero_memberbot__XSF_Memberbot__v2.png

hmm no I can't

Daniel, as you might have seen the "Redis woohoo!" commit is just here to bypass Redis as we didn't want to set it up to test our changes :-°

(also I'm curious if it's actually necessary..)

I was just blindly going to add strip().lower() in some places. I wasn't even going to run it

heh

Zash, XEP-0220 is also used by XEP-0288 - are you suggesting that the dialback auth is deprecated, or that the syntax itself is deprecated?

Maranda: rogue issuing of certs by LE?

dwd: Personally I really don't like the syntax. But I'm pretty sure you can do 288 without talking Dialback.

ralphm, Guus, can somebody give me perms on the trello board so I add agenda items please. ✏

pep., what is your username there?

ppjet6

pep., oh, interesting, I also found another one, which does have an avatar

I just added an avatar

but that one is maximebuquet

Yeah, that was the original username they gave me, and apparently it's possible to change it.

Not sure how long it sticks around

so it is one account then?

confusing

it is

(confusing)

Thanks I've been added

Well, I think I added both

ugh, weird

I though I already added you?

Are you there three times now? 😁

You added one of his accounts as guest

I promoted that one, and added the other for good measure.

So pep. is double important now

Internet is hard

nah

The *hard* parts are not the problems, the problems come from the *soft* part. No software, no problem. 😁

You beat the end boss?

RFC5891 says it obsoletes RFC3491, does that mean XMPP applications should stop using the Nameprep stringprep profile for domain names?

Well...

It turns out that there are some issues surrounding Precis and multiple versions of Unicode.

Understatement of the decade 🙂

ralphm, this isn’t PRECIS yet.

IDNA 2008?

That's a separate thing from stringprep

I’m looking at whether IDNA2008 can be used for the domainpart of JIDs instead of IDNA2003 + Nameprep.

That's not how it works

Is it not?

Link Mauve, for reference: https://mailarchive.ietf.org/arch/msg/xmpp/a-WhzOTyOq168GujQHgzQ1-DURI

Thanks.

Ah yes, I have read this email already.

This thread.

If IDNA 2008 replaces IDNA 2003 AND Nameprep then I've gotten it all backwards.

Zash, that’s what I get from the obsoletes header of the RFC, but I may be wrong.

I think you either do it using stringprep as earlier versions of XMPP Addresses, or using Precis using the latests incarnation of it

I've just replaced the IDNA part and kept the stringprep part

IDNA doesn't come into play until you start doing DNS

IDNA2008 did the same mistake (?) as PRECIS of relaxing the Unicode version from Unicode 3.2 to undefined version.

Related: The 1023 byte limit on JID parts is super weird given the 256 byte limit on DNS names.

I guess you can invent your own non-DNS based federation with looooooong server names.

Wouldn’t that break any XMPP software using IDNA*?

Define "using IDNA*"

Being mostly familiar with Prosody, I can say that it should work fine as long as you don't try to federate.

Because IDNA isn't applied until you start doing DNS lookups

So I shouldn’t use IDNA2003 nor IDNA2008 in my JID library at all?

Since it isn’t involved in DNS in any way?

Prosody's JID library doesn't use IDNA at least.

Ok.

I guess read https://tools.ietf.org/html/rfc7622#section-3.2 and https://tools.ietf.org/html/rfc6122#section-2.2

Or get a hold of Peter

One could probably interpret those texts as nameprep being basically the same as IDNA?

Nameprep uses IDNA, but there a bunch more.

Link Mauve, domainparts can be DNS names of U-labels, not A-labels, hence they are in ACE. IDNA converts U-labels to A-labels and is hence not needed for your JID library.

Note that RFC7622 is underspecified regarding domainparts, see also https://www.rfc-editor.org/errata/eid5789

> ifqdn = 1*1023(domainbyte) > a "domainbyte" is a byte used to represent a UTF-8 encoded Unicode code point that can be contained in a string that conforms to RFC 5890

Hmmm

and here lies the problem

> ifqdn = 1*(namepoint) > a "namepoint" is a UTF-8 encoded Unicode code point that satisfies the Nameprep profile of stringprep in RFC 6122

strike that, the ifqnd definition is not the problem, the textual description is

Note that those are from two separate RFCs

The first I pasted replaces the second.

Yep

Does the 7622 definition permit 1023 UTF-8 continuation bytes?

The problem is that RFC7622 only allows code points allowed in NR-LDH labels and U-labels

which excludes the colon for example, and I am pretty sure most of us have domainparts which include colons

Oh glob what's an NR-LDH label?

Colons?

non reserved letters digits hypen label

Zash, just have a look at https://www.rfc-editor.org/errata/eid5789

That's not allowed in domain names

And IP literals are in "good luck with that" territory

NR-LDH are the old style dns label format prior unicode, which just could include letters, digits and the hypen, hence the name

Aren't U-labels the new ones?

yes and no

on the wire DNS still uses LDH labels

hence IDNA

It's really not that hard

`to_ascii()` yes

bbl

edhelas, “when you join a chatroom (especially that one)”, which one?

Otherwise, congrats for the release!