XSF Discussion - 2021-05-13

  1. arc

    Almost board meeting time

  2. arc

    Who is here?

  3. MattJ


  4. arc

    Okay so we technically have quorum

  5. arc

    We really need to move beyond having half the board every week

  6. arc


  7. MattJ

    I'll send an email about some stuff, and this

  8. arc

    Thanks. If we need to move to monthly, longer meetings so be it. Its just frustrating to set time aside every week and most of the time we don't have attendance

  9. dwd

    Ooops. I am here, too, just distracted by Something Interesting I FOund On The Internet.

  10. arc

    Ok so, agenda?

  11. dwd

    Agenda, I cannot help with. But:

  12. arc

    Fiscal sponsorship update.. CoC..

  13. dwd

    * Financial Host stuff: I think we're waiting on Peter, though Sam has been pushing forward with draft policies etc.

  14. MattJ

    There is a pending PR for review

  15. dwd

    * CoC: I'm just coming to the end of my notice period, which has been pretty disruptive (and the job hunting bit beofrehand), so will get back onto this and the associated Provacy Policy I think we should have.

  16. MattJ

    I'd also like to work out what the next steps are on the CoC stuff

  17. MattJ


  18. MattJ


  19. dwd

    On a personal note, I will be changing employer at the end of the month. As part of this change, I'm dropping to 4 days a week, and I'm aiming to generally use that "extra" day for XSF and OSS stuff.

  20. MattJ

    Congratulations :)

  21. arc


  22. arc

    Ok, aob?

  23. dwd

    No, though I do have some thoughts/research on CoC I'd like to discuss.

  24. MattJ

    I think that was everything

  25. arc

    Go ahead

  26. dwd

    Primarily, we previously talked about a CoC based aorund positive behaviour we wanted to see. However, the research I've managed to do so far actually recommends against this.

  27. dwd

    This is somewhat to my surprise, to be honest.

  28. arc

    Why is that?

  29. dwd

    The argument is that it is easier for a bad actor to claim their behaviour is, for exampe, respectful ("But they're just deliberately taking it badly") than to argue it is not, for example, an ad-hominem attack.

  30. arc

    I totally get that. But do we really want to be in a position to parent bad actors?

  31. dwd


  32. dwd

    I'm merely saying that Codes of Conduct seem a lot more complicated than i'd hoped, and opnions seem generally divided on how to write them.

  33. arc


  34. dwd

    Anyway, it seems that any code of conduct we put in place is very likely to upset a bunch of people, and not only the people whose behaviour would be affected by a CoC.

  35. MattJ

    I've seen advocates of both styles. I can't claim to know the best option - I would personally prefer a positive-leading one, but I understand the concerns with that. My concern with a list of bad behaviours is that there is a potentially infinite list of such behaviours.

  36. dwd

    That's not to say we shouldn't put in place a CoC, but we need to manage the entire process carefully.

  37. MattJ

    https://www.contributor-covenant.org/ (originally posted by Sam) seemed good to me at a first glance, it struck me as a decent balance of both

  38. dwd

    Yes, but it's been a focus of political ire as well. Broadly adopted as-is by the Linux kernel community, and that met with quite some resistance.

  39. dwd

    There's also the Debian one, which seems to have been mostly controversy-free, but might not have been as effective as people would have liked.

  40. MattJ

    The Debian one controversy-free? :)

  41. dwd

    Anyway, I'm broadly leaning toward something like the FLOSSUK one - https://www.flossuk.org/about/code-of-conduct/- that seems to state aims in terms of positive behaviours, and then gives a non-exhuatsive list of bad behaviour.

  42. MattJ

    Not from the mailing lists I'm on

  43. MattJ

    I've yet to see a CoC adopted at any org without controversy

  44. MattJ

    But you know, we can be the first :)

  45. dwd

    MattJ, We can hope.

  46. arc

    Sounds like we have reached the end of the meeting?

  47. dwd

    Yes, sorry. Kind of rambling on a bit.

  48. arc

    These are important conversations

  49. arc

    But it sounds like we've come to a close so

  50. arc


  51. dwd

    Sounds good.

  52. arc

    Things the virtual gavel

  53. arc


  54. arc

    I have been driving so I'm on voice and put

  55. arc


  56. arc

    I also serve on the board of the neighborhood community garden which meets every week at 10:00 a.m.! 😅

  57. arc

    Meetings here are far less exciting than XSF board meetings. I'm the youngest member of this board by about 20 years

  58. moparisthebest

    so I accidentally discovered a DNS-only DOS against ejabberd, but also, my guess is, most other XMPP servers

  59. moparisthebest

    so here's the question, on outgoing S2S, if you don't *receive* anything over the connection, how can you be sure you are connected to what you should be ?

  60. moparisthebest

    do you... try to receive data on the connection and if you receive anything at all, abort it and move onto the next SRV record ? or what ?

  61. moparisthebest

    how do you avoid the case where someone who only controls your DNS, or someone who only controls a route between you and 1 of the SRV records, can entirely block your ability to connect to the remote domain ?

  62. MattJ

    Mmm, that's not really preventable, is it? :)

  63. MattJ

    If they control it they can drop DNS/SYN

  64. moparisthebest

    yea possibly DNS isn't able to be worked around, what about the second case though ?

  65. moparisthebest

    you have 2 SRV targets in different locations, an attacker who controls only the route to the lowest priority one shouldn't be able to prevent you from falling back to the second, right ?

  66. moparisthebest

    right now, with ejabberd, and I suspect most other servers, if you redirect the first to an HTTPS server for instance, the second is never attempted

  67. moparisthebest

    (I accidentally broke all incoming federation from ejabberd servers to mine this way :))

  68. moparisthebest

    c2s doesn't suffer from this problem because it's bi-directional

  69. Kev

    But C2S does suffer the same problem.

  70. Kev

    If you can drop someone’s connections, you can drop someone’s connections.

  71. Kev

    Or I’ve not understood properly.

  72. moparisthebest

    dropping is easy, you can fallback to the next SRV record

  73. Kev

    When, though?

  74. moparisthebest

    and if you've validated the TLS properly, and get valid XMPP, you are connected to a c2s port

  75. Kev

    If you connect and authenticate to the server ok, and then it drops, you shouldn’t drop back to the other SRV should yoU?

  76. moparisthebest

    how do you determine if you've connected to a valid s2s port though

  77. Kev

    It doesn’t matter, does it?

  78. Kev

    If your transit is malicious, it will allow enough through to cause you to authenticate, and then terminate.

  79. Kev

    (Which is much easier with C2S than S2S, because of rountrip counting)

  80. Kev

    And because you had a live connection, you won’t fallback.

  81. Kev

    So even “If I didn’t manage to authenticate, fallback” doesn’t save you there.

  82. moparisthebest

    what's the point of SRV records if having the first one misbehave blocks you from trying the rest ?

  83. Kev

    What does ‘misbehave’ mean though?

  84. moparisthebest

    so maybe it needs some consideration in c2s too "if the connection is "too flakey" (todo: define "too flakey") fallback"

  85. moparisthebest

    misbehave as in anything someone not in control of the TLS certificate can do

  86. Kev

    Flakiness protection is horrible, but it’s what you’d need here, yes.

  87. Kev

    (And the same for S2S)

  88. Kev

    We actually do have protection against this sort of thing for our X2X support, but less so for S2S.

  89. Kev

    (Because, as you noted, bidirectional)

  90. moparisthebest

    so what's a start for defense against this in S2S? only what I mentioned? > try to receive data on the connection and if you receive anything at all, abort it and move onto the next SRV record ?

  91. Kev

    afk sorry

  92. moparisthebest

    I guess that brings back my question from the other day, do any XMPP servers in the wild ever send anything over normal (non-bidi) incoming S2S connections ?

  93. MattJ

    Except for stream header, stream errors, stream close, and potentially 198 or whitespace... no?

  94. Kev

    Matt - I saw you removed dwd from Prosody, was that just getting rid of dialback stuff, or you found security issues, or …?

  95. Kev

    (Or did I misread the release notes)

  96. Zash

    Only the part that's mostly equivalent to SASL EXTERNAL

  97. Kev

    Hmm. Is it?

  98. dwd

    I kept calling it LUA.

  99. Zash

    Kev: It had a security issue, but we opted to remove it. We don't have any test coverage and poor confidence in it working correctly.

  100. moparisthebest

    MattJ, I think they only send pre-TLS stuff, after TLS is started it seems even stream errors are sent over the other connection ?

  101. Kev

    Stream errors always have to be sent over the stream they relate to.

  102. Zash

    And by "equivalent to SASL EXTERNAL" I mean that it could optionally check your dialback request against the cert and short-circuit it.

  103. Zash

    It was disabled by default and I don't think I ever saw it used.

  104. moparisthebest

    I'll have to test again, I swear I saw them being sent over the other one...

  105. Zash

    Not sure if it was even documented.

  106. Kev

    I’m not going to say you didn’t see it - but you shouldn’t have :)

  107. Zash

    moparisthebest, dialback stuff too maybe, in addition to the stuff MattJ listed

  108. moparisthebest

    if there doesn't exist a way to *request* something back on the same connection (that won't terminate it, like a stream error), maybe that's the solution

  109. Kev

    198 can request traffic.

  110. moparisthebest

    a simple ping, but on this s2s connection

  111. MattJ

    moparisthebest: a solution, but I'm not sure I understand the problem

  112. Kev

    I don’t think it’s a solution to the proposed problem, if we’re still on “transit terminates your connection as a DOS"

  113. moparisthebest

    the problem is, once an S2S connection is established, and TLS verified, how do you detect if you are actually connected to an XMPP server, or something else (like HTTPS)

  114. moparisthebest

    because if you aren't you need to fallback to the next SRV target

  115. Kev

    If you’re not connected to S2S you don’t get stream headers?

  116. Kev

    And if by ‘established’ you mean you’ve already authenticated, doesn’t that mean you already know you’re S2S?

  117. moparisthebest

    the pre-TLS ones ?

  118. Kev

    The post-TLS ones.

  119. Kev

    But the pre-TLS ones if you’re doing starttls mean you’re talking to XMPP too.

  120. moparisthebest

    not necessarily

  121. moparisthebest

    an evil MITM in front of that target could fake XMPP before TLS, then just redirect traffic from an HTTPS server with the proper certificate

  122. Kev

    That would be why you bin everything once you start TLS.

  123. Kev

    (Well, ‘that’ - that you can’t trust pre-TLS in general)

  124. moparisthebest

    it does protect against accidental misconfiguration, just not active attacks

  125. moparisthebest

    which is why I suspect this bug has lasted so long in SRV implementations, it's just easier to spot with direct TLS

  126. MattJ

    It's not really a bug, it's just the internet

  127. moparisthebest

    if your SRV implementation connects, tries to send a stanza, gets an HTTP response and the connection is closed, and it doesn't fallback to the next SRV target, that's a bug

  128. MattJ

    It's suboptimal behaviour, yes :)

  129. Zash

    You're forgetting the stream header there