XSF Discussion - 2022-01-24

Hang on, i didnt even check if i support it cause its libstrophe scope not mine, but is it just not used?

What the heck even is it

SASL mechanism family, i.e. authentication

Right, whats special about it? Libstrophe definitely does sasl just fine as current 😶

Password doesn't need to be stored anywhere or sent during auth, only hashes.

Huh, cool

It additionally only sends a further hash (a hash of a hash), itself encrypted, over the wire.

Paranoia-level key transfer

Unfortunately it's tricky to upgrade that hash without a service-wide password reset, so these efforts to push for SCRAM-SHA-256 and others is mostly harmful and leads to problems.

Gotcha

All major XMPP Servers support it, clients must to support it. ✏

The server software may support it, but actual deployments? Almost none.

As mentioned earlier, it would require every user to reset their password

As an aside: Martin was more than right in his response in the 'renew Mozilla Thunderbird' PR. We must not repeat this behaviour.

Thanks for responding immediately, emus.

yes, sure

Neustradamus: there is an acceptable level of nudging volunteer/unpaid projects into doing more work, and that limit can be reached very very quickly

(Randomly pinging people on github crosses the threshold in a single step, obviously)

It's really not worth engaging with this user; they love to ping tons of people all at once constantly. I can never tell if they're trolling, or if it's a language barrier, or if they just have some social problems but I can never get them to actually respond in a useful way either no matter how patient I was so I just gave up, it's not worth the time when they won't actually engage in discussing whatever perceived problem they think they're helping with.

I have excused to the two big teams that got multiple pings

I reached out personally to the Thunderbird developer. Everything is alright and they understand.

Thanks emus.

This sort of thing really isn't a good look.

Fun fact: On one of my Board stints I got quite far with getting DNSSEC support into the Isle of Man (.IM) registry, using various personal contacts through to their technical director, until someone decided to contact them directly without any introduction or coordination and just demanded they support DNSSEC because XMPP. I stopped getting replies after that, and I'm not surprised.

Sadness

In the specific case of SCRAM, the SHA-3 variants have recently had push back at the IETF (as Sam and others will know) because of the problems of hash agility in deployment that Zash mentions earlier. SHA-1 isn't "great", certainly, but we need a better story for migrating than "Everyone change your password today!"

"everybody change your password soon" and have a transition period where you collect both hash types during password changes

but it's messy nontheless

And with a sufficiently large site, there will be at least one straggler that _never_ changes password and halts that migration attempt.

jonas’, Yeah, nah. You can only usefully offer SCRAM-SHA-3 (yes, I know) once all users have changed.

Use plain, if you use your XMPP password elsewhere you are a bad person and should be ashamed

moparisthebest, looks like a downgrade attempt, won't work, clients will balk

I think they mean 'use only PLAIN, ever', which is how lots of deployments have to work anyway.

moparisthebest, Also allows credential theft and impersonation attacks, which SCRAM doesn't. Well, not trivially, anyway.

Kev, Indeed.

Kev, but that makes me sad.

Correct, always use plain always

For those who already use scram, oops

moparisthebest, Of course, the correct solution is "use X.509 always", and then frantically handwave when someone mentions key distribution.

You can force PLAIN and collect everyones password in plain text, then upgrade them to SCRAM-whatever

Haha yea dwd

Dance Dance Key Distribution

Everyone should authenticate with their OMEMO key

Never!

Buuuuuut ... there's an RFC for using OpenPGP keys in TLS

and then SASL EXTERNAL

Actually, OMEMO for subsequent auth isn't a bad idea. I think there's enough cryptomagic in the prekeys for the server to authenticate, right?

That leaves initial auth, and I think there's enough evidence that initial and subsequent authentication are radically different things now.

Does this magically solve the device tracking thing too?

Zash, Well, it begins to throw everything in a big pile together that looks like it might all be related, I think.

Like everything isn't already in a big pile.

Zash, Back when I was looking at MLS - and I still think that might eventually be a good idea - I was thinking that a dedicated client init key service made more sense than PEP. And tying that into device registration/management also makes sense. If you can unify subsequent authenticaiton into that, then there's only device feature publication and push left I *think*, both of which could connect in nicely.

Zash, And by "nicely" I mean "horribly", but you knew that.

Everything is PEP these days.

Finally living the dream of "everything is pubsub" !

Zash, Yes, but for prekeys/client init keys, PEP means that an attacker - in principle - could deliberately pick the same prekey as another conversation and therefore could - in theory - mount some kind of hithertofore undiscovered attack on the cryptography. Or could pick a weak (unspecified what this means) prekey. The other systems using similar hide the keys to avoid these attacks. They're theoretical - there's no known weakness in different keys, or key reuse, but the cryptanalysis of both Axolotl/Signal and MLS is predicated on the prekeys not being reused, so in theory blah-de-blah. Plus there's slightly more visibility on how many conversations the target is having, I think.

Zash, PEP is a load more immediately deployable though.

You had me at blah-de-blah.

Zash, I hoped you'd stopped reading by that point.

I do wonder if maybe it's time to have a dedicated roster-of-sorts for MUC bookmarks.

Zash, Well, I occasionally wonder about MUC-PAM and things, so yeah.

And a crypto key thingymajigger for OMEMO

Zash, Oh, a thingymajigger. Yeah.

Surely there's a yet to be discovered section of XEP-0060 that would solve this problem with some sort of FIFO queue

or .. FIR(andom)O ?

Zash, XEP-0254?

Based on the title, probably ✏

Zash, But prekeys (and MLS client init keys) benefit from a random "grab and remove" until the bucket runs low, then a "grab and mark used" such that when the bucket is refilled, the used ones can be removed.

Zash, It's an unusual pattern elsewhere. Plus it benefits from the contents of the bag being unknown.

Zash, I mean, the benefit is only marginal. But still.

dwd: Of course. I apologized and made clear this is not how we act here and he fully understood and said it did not affect him, he was just sorry for the volunteers and not related people. I hope most of them got this info.

we should seriously consider blocking them from the xsf org for this.

I thought about reporting to github, but all the reporting reasons require that you're affected directly, which I personally am not in this instance.

As an organisation yes