XMPP Council - 2013-08-21


  1. Lance has left

  2. m&m has joined

  3. m&m has left

  4. m&m has joined

  5. m&m has left

  6. Lance has left

  7. m&m has joined

  8. m&m has left

  9. Tobias has joined

  10. Neustradamus has joined

  11. Lance has left

  12. Tobias has joined

  13. Tobias has joined

  14. Kev

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

  15. jabberjocke has joined

  16. m&m has joined

  17. Neustradamus has joined

  18. Tobias has left

  19. Tobias has joined

  20. jabberjocke has left

  21. m&m has left

  22. m&m has joined

  23. ralphm has joined

  24. ralphm waves

  25. m&m has left

  26. Kev

    Hi Ralph.

  27. Tobias has joined

  28. Kev

    10mins:)

  29. Tobias has left

  30. ralphm

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

  31. Kev

    Seems reasonable.

  32. Tobias has joined

  33. Tobias

    Jtalk's muc is still a bit buggy

  34. psaintan has joined

  35. psaintan

    greetings

  36. Tobias

    Guten tag

  37. ralphm

    Goede dag!

  38. psaintan

    :)

  39. Tobias

    Interestingly jtalk lists all my multi session nicks

  40. psaintan

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

  41. Kev

    IIt is time.

  42. Kev

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

  43. Kev

    1) Roll call.

  44. Kev

    M&M sends apologies.

  45. Kev

    I'm here.

  46. ralphm

    here

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

  48. Tobias

    Here

  49. ralphm

    psaintan: fancy

  50. Kev pokes MattJ

  51. Tobias has left

  52. Kev

    Tobias leaves in disgust.

  53. psaintan

    :)

  54. ralphm

    Still one left, I guess

  55. Tobias has joined

  56. Tobias

    Still there

  57. Kev

    2) Stuff stuck at proposed.

  58. 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

  59. Kev

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

  60. MattJ has joined

  61. Kev

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

  62. psaintan

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

  63. 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.

  64. psaintan

    we can ping fippo about 288

  65. psaintan

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

  66. Tobias

    Bidi not though

  67. Kev

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

  68. MattJ

    Yes, I think so

  69. ralphm

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

  70. Tobias

    Fine with me

  71. MattJ

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

  72. 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.

  73. 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 :)

  74. Kev

    At least from what I understand.

  75. psaintan

    right

  76. Kev

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

  77. MattJ

    psaintan, can they function without dialback at the moment?

  78. Kev

    Did I miss anything for this week?

  79. Kev

    ProtoXEPs or whatever.

  80. ralphm

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

  81. psaintan

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

  82. psaintan

    ralphm: for initial connections, yes

  83. psaintan

    ralphm: for piggybacked domain pairs, unclear

  84. ralphm nods

  85. Kev

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

  86. Kev

    OK.

  87. Kev

    3) Date of next.

  88. ralphm

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

  89. Kev

    SBTSBC?

  90. ralphm

    ?

  91. psaintan

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

  92. psaintan

    ralphm: the DNA stuff is

  93. ralphm

    right

  94. Kev

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

  95. Kev

    4) AOB

  96. psaintan

    Kev: yes :-)

  97. ralphm

    Kev: yes

  98. Tobias

    Yes on the time

  99. Kev

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

  100. MattJ

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

  101. MattJ

    +1

  102. MattJ

    and I'm replying to that post...

  103. psaintan

    huh?

  104. psaintan

    oh

  105. Kev

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

  106. MattJ

    psaintan, see Simon's latest email

  107. psaintan

    I started reading that but hadn't gotten that far

  108. psaintan

    agreed on the naming!

  109. Tobias

    Hehe

  110. Kev

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

  111. psaintan

    Kev: TLS anyway

  112. psaintan

    channel encryption

  113. psaintan

    with cert checking

  114. Kev

    Cert checking...for what?

  115. Kev

    CAs?

  116. psaintan

    RFC 6125 stuff

  117. ralphm

    Kev: I guess we're done here?

  118. Tobias has left

  119. Kev

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

  120. Kev

    Thanks all.

  121. psaintan

    :)

  122. Kev bangs the gavel

  123. Tobias has joined

  124. Kev

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

  125. Kev

    s/certs/CRLs/

  126. Tobias

    Thanks

  127. psaintan

    well, no one does OCSP as I understand it

  128. Kev

    That was somewhat my point.

  129. psaintan

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

  130. Tobias

    Peter, and crls?

  131. 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.

  132. psaintan

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

  133. Tobias

    What servers do crl?

  134. Kev

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

  135. Kev

    And even then, only by configuration I think.

  136. 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)

  137. Tobias

    Yup. 3rd party fetching

  138. Kev

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

  139. Kev

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

  140. 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

  141. psaintan

    maybe we wait until Google turns off federation

  142. Tobias

    Peter, nobody knows when that is though

  143. psaintan

    sure

  144. psaintan

    so perhaps we need to take the lead

  145. psaintan

    we don't necessarily make it permanent at first

  146. psaintan

    we can experiment as people did with IPv6

  147. Kev

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

  148. psaintan

    heh

  149. Kev

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

  150. psaintan

    I'm in favor of c2s first of all

  151. psaintan

    that's an easier step to take

  152. Kev

    That one is much easier.

  153. psaintan

    yes

  154. psaintan

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

  155. 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

  156. Kev

    Require SCRAM-SHA1-PLUS with TLS where possible.

  157. Kev

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

  158. Tobias has left

  159. Kev

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

  160. Kev

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

  161. Kev

    I think (3) might be a little optimistic.

  162. psaintan

    that seems eminently reasonable

  163. Tobias has joined

  164. psaintan

    I wonder which server products have configuration bits for these things

  165. psaintan

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

  166. MattJ

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

  167. Kev

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

  168. psaintan

    Kev: yes

  169. Kev

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

  170. MattJ

    and as a config option to enforce TLS

  171. MattJ

    and has a config option to enforce TLS

  172. Kev

    And then gently encourage admins to move towards it.

  173. psaintan

    we might have carrots and we might have sticks

  174. Kev

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

  175. psaintan

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

  176. ralphm

    Kev: why?

  177. psaintan

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

  178. Kev

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

  179. Kev

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

  180. ralphm

    Kev: surely you have statistics on this?

  181. psaintan

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

  182. Kev

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

  183. ralphm

    oh

  184. 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.

  185. Kev

    But anyway.

  186. Tobias

    <3 stats

  187. Kev

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

  188. psaintan

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

  189. Kev

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

  190. psaintan

    yes

  191. Kev

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

  192. psaintan

    :)

  193. psaintan

    indeed

  194. psaintan

    one step at a time

  195. Kev

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

  196. psaintan

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

  197. Kev

    psaintan: 'tis all I ask.

  198. psaintan

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

  199. Tobias

    psi's just got scram without plus

  200. psaintan

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

  201. Kev

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

  202. Zash has joined

  203. Tobias

    Kev, interop wise it does

  204. Kev

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

  205. Tobias

    Sure

  206. Tobias has left

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

  208. ralphm

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

  209. ralphm

    even DIGEST

  210. ralphm

    eh

  211. ralphm

    PLAIN

  212. psaintan

    heh

  213. Kev

    In terms of interop, yes.

  214. Kev

    In security properties, maybe not.

  215. ralphm

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

  216. Kev

    Then DIGEST-MD5 > *, yes.

  217. Kev

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

  218. ralphm

    Kev: no

  219. Tobias has joined

  220. Tobias has left

  221. 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

  222. Tobias has left

  223. Lance has joined

  224. Tobias has joined

  225. Tobias has left

  226. Neustradamus has joined

  227. Kev

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

  228. Zash

    Heh

  229. MattJ

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

  230. MattJ

    It's a question of deployment, not implementation

  231. Kev

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

  232. MattJ

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

  233. Kev

    Could be.

  234. 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.

  235. Kev

    Depending what the things people are concerned about are.

  236. m&m has joined

  237. psaintan

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

  238. psaintan

    but yeah, agreed on operators@

  239. psaintan

    brb

  240. Neustradamus has joined

  241. Zash has left

  242. Zash has joined

  243. Tobias has joined

  244. bear has left

  245. bear has joined

  246. psaintan has left

  247. m&m has left

  248. Zash has joined