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