XMPP Council - 2013-08-21

  1. Kev

    The only thing I have on the agenda for today is the list of purgatory XEPs Peter mailed 'round.

  2. ralphm waves

  3. Kev

    Hi Ralph.

  4. Kev


  5. ralphm

    Kev: I always aim for :00, so I'm surely on time

  6. Kev

    Seems reasonable.

  7. Tobias

    Jtalk's muc is still a bit buggy

  8. psaintan


  9. Tobias

    Guten tag

  10. ralphm

    Goede dag!

  11. psaintan


  12. Tobias

    Interestingly jtalk lists all my multi session nicks

  13. psaintan

    m&m is in the JSON WG meeting all day and won't join us here

  14. Kev

    IIt is time.

  15. Kev

    psaintan: He said last week he couldn't make it - although I was hoping he'd suggest a better time.

  16. Kev

    1) Roll call.

  17. Kev

    M&M sends apologies.

  18. Kev

    I'm here.

  19. ralphm


  20. psaintan is here via his @cisco.com JID

  21. Tobias


  22. ralphm

    psaintan: fancy

  23. Kev pokes MattJ

  24. Kev

    Tobias leaves in disgust.

  25. psaintan


  26. ralphm

    Still one left, I guess

  27. Tobias

    Still there

  28. Kev

    2) Stuff stuck at proposed.

  29. Kev

    XEP-0152: Reachability Addresses XEP-0220: Server Dialback XEP-0288: Bidirectional Server-to-Server Connections XEP-0297: Stanza Forwarding XEP-0301: In-Band Real Time Text

  30. Kev

    Does it seem sensible to vote on them going to Draft next week?

  31. Kev

    I need to review the 301 diff (Please, everyone else, do feel free to do a review and comment!).

  32. psaintan

    fippo sent me some editorial nits about 220 and I will process those ASAP

  33. Kev

    I keep hoping to have a chance to do a cleanroom implementation of 220, but then I don't get around to it, so that's no reason to delay.

  34. psaintan

    we can ping fippo about 288

  35. psaintan

    yeah, dialback has been stable for a long time :-)

  36. Tobias

    Bidi not though

  37. Kev

    So, everyone ok with just voting on the lot next week?

  38. MattJ

    Yes, I think so

  39. ralphm

    just out of curiousity, apart from GTalk connectivity, how much do we still need dialback?

  40. Tobias

    Fine with me

  41. MattJ

    I have some small modifications to make to 297, so I'll push those this week

  42. Kev

    ralphm: We might not want to use the in-dialback proof method, but I think we still want to keep the dialback protocol stuff around.

  43. psaintan

    ralphm: well, POSH and DNA and such actually use dialback for signalling, about piggybacking so I think we'll keep it around for a while longer :)

  44. Kev

    At least from what I understand.

  45. psaintan


  46. Kev

    OK. So that's all on the agenda for a vote next week.

  47. MattJ

    psaintan, can they function without dialback at the moment?

  48. Kev

    Did I miss anything for this week?

  49. Kev

    ProtoXEPs or whatever.

  50. ralphm

    I knew about all this, of course, but still wondering if the landscape has changed enough to do everything with regular tls/sasl

  51. psaintan

    MattJ: see http://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/ and provide feedback on the xmpp@ietf.org list :-)

  52. psaintan

    ralphm: for initial connections, yes

  53. psaintan

    ralphm: for piggybacked domain pairs, unclear

  54. ralphm nods

  55. Kev

    Shoving SASL exchanges into the middle of a stream would be somewhat unorthodox.

  56. Kev


  57. Kev

    3) Date of next.

  58. ralphm

    psaintan: is this a point of attention in the XMPP WG

  59. Kev


  60. ralphm


  61. psaintan

    although (AOB) I would like to start pushing the communityforward to fully encrypted hops

  62. psaintan

    ralphm: the DNA stuff is

  63. ralphm


  64. Kev

    I'll take that as a 'yes' to SBTSBC, then.

  65. Kev

    4) AOB

  66. psaintan

    Kev: yes :-)

  67. ralphm

    Kev: yes

  68. Tobias

    Yes on the time

  69. Kev

    So, SEX day. Please, for the love of all that's good, let's not call it SEX day.

  70. MattJ

    Kev, you could just have the whole meeting yourself :P

  71. MattJ


  72. MattJ

    and I'm replying to that post...

  73. psaintan


  74. psaintan


  75. Kev

    I realise as geeks we have the humour capabilities of a three-year-old, but still.

  76. MattJ

    psaintan, see Simon's latest email

  77. psaintan

    I started reading that but hadn't gotten that far

  78. psaintan

    agreed on the naming!

  79. Tobias


  80. Kev

    psaintan: Do we know what 'fully encrypted' means?

  81. psaintan

    Kev: TLS anyway

  82. psaintan

    channel encryption

  83. psaintan

    with cert checking

  84. Kev

    Cert checking...for what?

  85. Kev


  86. psaintan

    RFC 6125 stuff

  87. ralphm

    Kev: I guess we're done here?

  88. Kev

    Yeah, I'm happy enough that this is a tangent.

  89. Kev

    Thanks all.

  90. psaintan


  91. Kev bangs the gavel

  92. Kev

    psaintan: So, this means that any server not automatically fetching certs and doing OCSP and stuff should stop federating, right?

  93. Kev


  94. Tobias


  95. psaintan

    well, no one does OCSP as I understand it

  96. Kev

    That was somewhat my point.

  97. psaintan

    Kev: I know you're tired and overworked, so please just s/fully// and we'll move on

  98. Tobias

    Peter, and crls?

  99. Kev

    I wasn't being entirely belligerent. If we want to have a big 'turn off encryption and partition the network' event, I think we should have a reasonable handle on what's involved.

  100. psaintan

    well, sure, people should do all that stuff, but at least doing RFC 6125 checks is a good idea

  101. Tobias

    What servers do crl?

  102. Kev

    Tobias: Fully, without having to fetch manually? Just M-Link of which I'm aware.

  103. Kev

    And even then, only by configuration I think.

  104. psaintan

    I'm not necessarily in favor of a flag day, but it would be a step in the right direction if several of the larger nodes required TLS and proper certs (and we had helpful HOWTOs in place so that admins of other servers could get up to speed)

  105. Tobias

    Yup. 3rd party fetching

  106. Kev

    I'd suggest we just go with 'require unchecked TLS' first.

  107. Kev

    And this does effectively blackhole gmail, which isn't something I'm entirely comfortable with..

  108. psaintan

    CRLs and OCSP are two solutions to a problem that might be solved in other ways (e.g., shorter-lived certificates), but that's a wider discussion

  109. psaintan

    maybe we wait until Google turns off federation

  110. Tobias

    Peter, nobody knows when that is though

  111. psaintan


  112. psaintan

    so perhaps we need to take the lead

  113. psaintan

    we don't necessarily make it permanent at first

  114. psaintan

    we can experiment as people did with IPv6

  115. Kev

    I don't think anyone (significant)'s tried promoting IPv6 by turning off v4 though, have they?

  116. psaintan


  117. Kev

    I'm not anti-TLS-on-S2S, although I realise my "Let's think this through" sounds a bit like it.

  118. psaintan

    I'm in favor of c2s first of all

  119. psaintan

    that's an easier step to take

  120. Kev

    That one is much easier.

  121. psaintan


  122. psaintan

    and will help us isolate some bugs, fix some software out there in the world, etc.

  123. Kev

    I'd be happy with someone coming up with a list of steps on the road to secure XMPP, and it probably looks a bit like: No PLAIN/78 without TLS No C2S without TLS

  124. Kev

    Require SCRAM-SHA1-PLUS with TLS where possible.

  125. Kev

    (e.g. it's not possible while backing on to AD or whatever)

  126. Kev

    I'd be very happy to sort out (1) on j.org, finally.

  127. Kev

    Then plan to do (2) in a couple of months.

  128. Kev

    I think (3) might be a little optimistic.

  129. psaintan

    that seems eminently reasonable

  130. psaintan

    I wonder which server products have configuration bits for these things

  131. psaintan

    and whether we need to figure that out for the more widely-deployed servers

  132. MattJ

    Prosody already disallows PLAIN (or legacy auth, if enabled) on unencrypted connections - and most clients do anyway

  133. Kev

    I think it'd be good to sort out a roadmap to security.

  134. psaintan

    Kev: yes

  135. Kev

    And then we can let the vendors have this, so we know that software can do it.

  136. MattJ

    and as a config option to enforce TLS

  137. MattJ

    and has a config option to enforce TLS

  138. Kev

    And then gently encourage admins to move towards it.

  139. psaintan

    we might have carrots and we might have sticks

  140. Kev

    MattJ: M-Link has a config option to re-enable PLAIN without TLS, and we've got that switched on on jabber.org

  141. psaintan

    xmpp.net might have a role to play here in reporting and self-testing

  142. ralphm

    Kev: why?

  143. psaintan

    I do wonder if prosody-users and buddycloud-dev are the right venues for the discussion :-)

  144. Kev

    ralphm: Because when we initially deployed, there were so many users that suddenly couldn't connect.

  145. Kev

    Maybe, three years on, this wouldn't be the case.

  146. ralphm

    Kev: surely you have statistics on this?

  147. psaintan

    Kev: yeah, a lot of those users were on old OS X releases IIRC

  148. Kev

    ralphm: Could generate stats, but I don't have any to hand.

  149. ralphm


  150. Kev

    But we can't generate stats or whether those users have just configured their client in a stupid way, or don't have another option in their client for some reason.

  151. Kev

    But anyway.

  152. Tobias

    <3 stats

  153. Kev

    I'm entirely in favour of just making an announcement once the migration dust has settled and disabling this option on jabber.org

  154. psaintan

    Kev: yes, I've been waiting to bring up such issues until after the migration

  155. Kev

    And then making another announcement and after a couple of months requiring TLS.

  156. psaintan


  157. Kev

    I'd /like/ to then require SCRAM-SHA1-PLUS, but that's a bit trickier :)

  158. psaintan


  159. psaintan


  160. psaintan

    one step at a time

  161. Kev

    Although at least Tobias and I are using clients that'd work fine with. Anyone else? :)

  162. psaintan

    I think we all agree on the goal, but we need to be prepared and think through the various issues that will arise

  163. Kev

    psaintan: 'tis all I ask.

  164. psaintan

    Kev: I use Swift for stpeter@jabber.org but in Psi at the moment

  165. Tobias

    psi's just got scram without plus

  166. psaintan

    and flipping multiple switches at once is a recipe for not understanding what's causing various problems

  167. Kev

    SCRAM without PLUS isn't much better than DIGEST-MD5 :)

  168. Tobias

    Kev, interop wise it does

  169. Kev

    Or, at least, it's the -PLUS magic that's relevant to the TLS conversation.

  170. Tobias


  171. psaintan reviews various emails about XEP-0220 so we can advance it

  172. ralphm

    Kev: everything is much better than DIGEST-MD5 in my humble opinion

  173. ralphm

    even DIGEST

  174. ralphm


  175. ralphm


  176. psaintan


  177. Kev

    In terms of interop, yes.

  178. Kev

    In security properties, maybe not.

  179. ralphm

    and in terms of bat shit crazy omgbbq who the hell thought this up

  180. Kev

    Then DIGEST-MD5 > *, yes.

  181. Kev

    Although I think this is more just a case of 'things have got better, we're better at doing this now'.

  182. ralphm

    Kev: no

  183. ralphm

    Kev: i.e. your colleagues (among others) were already discussing all the bad things in DIGEST-MD5 over a decade ago over in the sasl wg

  184. Kev

    I wonder if at any point Simon's going to move this discussion somewhere a bit more appropriate than prosody-users.

  185. Zash


  186. MattJ

    Yes, operators@ would have been more appropriate I think :)

  187. MattJ

    It's a question of deployment, not implementation

  188. Kev

    operators@, or if he wants it to be XSF-endorsed, members@

  189. MattJ

    (at this point I think all popular implementations are capable of what we're discussing)

  190. Kev

    Could be.

  191. Kev

    Although I think doing some self-signed CA leap-of-faith-with-dialback stuff would possibly be better than public-CA-based PKI stuff.

  192. Kev

    Depending what the things people are concerned about are.

  193. psaintan

    OK, I've incorporated fippo's feedback on 220

  194. psaintan

    but yeah, agreed on operators@

  195. psaintan