XSF Discussion - 2022-01-24


  1. qy

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

  2. qy

    What the heck even is it

  3. Zash

    SASL mechanism family, i.e. authentication

  4. qy

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

  5. Zash

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

  6. qy

    Huh, cool

  7. dwd

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

  8. qy

    Paranoia-level key transfer

  9. Zash

    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.

  10. qy

    Gotcha

  11. Neustradamus

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

  12. Neustradamus

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

  13. MattJ

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

  14. MattJ

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

  15. guus.der.kinderen

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

  16. guus.der.kinderen

    Thanks for responding immediately, emus.

  17. emus

    yes, sure

  18. mathieui

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

  19. mathieui

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

  20. Sam

    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.

  21. emus

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

  22. emus

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

  23. Kev

    Thanks emus.

  24. Kev

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

  25. dwd

    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.

  26. Zash

    Sadness

  27. dwd

    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!"

  28. jonas’

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

  29. jonas’

    but it's messy nontheless

  30. Zash

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

  31. dwd

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

  32. moparisthebest

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

  33. Zash

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

  34. Kev

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

  35. dwd

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

  36. dwd

    Kev, Indeed.

  37. Zash

    Kev, but that makes me sad.

  38. moparisthebest

    Correct, always use plain always

  39. moparisthebest

    For those who already use scram, oops

  40. dwd

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

  41. Zash

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

  42. moparisthebest

    Haha yea dwd

  43. Zash

    Dance Dance Key Distribution

  44. moparisthebest

    Everyone should authenticate with their OMEMO key

  45. moparisthebest runs away before being asked practical questions

  46. Zash

    Never!

  47. Zash

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

  48. Zash

    and then SASL EXTERNAL

  49. dwd

    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?

  50. dwd

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

  51. Zash

    Does this magically solve the device tracking thing too?

  52. dwd

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

  53. Zash

    Like everything isn't already in a big pile.

  54. dwd

    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.

  55. dwd

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

  56. Zash

    Everything is PEP these days.

  57. Zash

    Finally living the dream of "everything is pubsub" !

  58. dwd

    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.

  59. dwd

    Zash, PEP is a load more immediately deployable though.

  60. Zash

    You had me at blah-de-blah.

  61. dwd

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

  62. Zash

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

  63. dwd

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

  64. Zash

    And a crypto key thingymajigger for OMEMO

  65. dwd

    Zash, Oh, a thingymajigger. Yeah.

  66. Zash

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

  67. dwd nods sagely.

  68. Zash

    or .. FIR(andom)O ?

  69. dwd

    Zash, XEP-0254?

  70. Zash

    Based on the title, probable

  71. Zash

    Based on the title, probably

  72. dwd

    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.

  73. dwd

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

  74. dwd

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

  75. emus

    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.

  76. jonas’

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

  77. jonas’

    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.

  78. emus

    As an organisation yes