XMPP Council - 2013-09-12

  1. Lance has joined
  2. Lance has joined
  3. m&m has joined
  4. m&m has left
  5. m&m has joined
  6. stpeter has joined
  7. m&m has left
  8. Lance has joined
  9. Lance has joined
  10. Lance has joined
  11. Lance has joined
  12. Tobias has joined
  13. stpeter has left
  14. Lance has left
  15. tato has left
  16. Tobias has joined
  17. Tobias has joined
  18. Kev has joined
  19. Tobias has left
  20. Tobias has joined
  21. Tobias has left
  22. Tobias has joined
  23. Zash has joined
  24. m&m has joined
  25. Zash Why, Dave Cridland, why?
  26. ralphm Zash: disappointed he joined Twitter?
  27. Zash Who what why where how?
  28. Zash re http://logs.xmpp.org/council/130911/#19:47:26
  29. Kanchil Zash: http://logs.xmpp.org/council/130911/#19:47:26: Chatroom logs for council@muc.xmpp.org (Wednesday, September 11, 2013)
  30. Dave Cridland Zash, Certificate pinning via TACK?
  31. Dave Cridland Zash, Seems like a substantial amount of work for little gain. You can get the same general protection from DANE - that is, protection from third-party CAs issuing bad certs - with a lot more, for less effort.
  32. Zash Dave Cridland: But TACK seems to have a bigger marketing budget!
  33. Zash So it'll win!
  34. Zash :(
  35. Dave Cridland The advantage of TACK is that is handles this particular pinning case without infrastructure support. That's certainly useful, of course.
  36. Zash ralphm: Why is Thijs "xnyhps" not on planet jabber yet? :)
  37. Tobias but TACK doesn't seem to be implemented in the foreseeable future, or is it?
  38. Zash DNSSEC deployment isn't that fast either
  39. Dave Cridland Tobias, TLSlite implements it I think. I assume so anyway.
  40. Dave Cridland Zash, That *seems* faster to me.
  41. Tobias TLSlite, what's that? the python tls implementation
  42. Zash Something like HSTS for XMPP should be fairly simple ...
  43. Tobias is HSTS really needed? TLS is the default in the XMPP world, unlike the HTTP world
  44. Dave Cridland The intent is to protect against future downgrade attacks.
  45. Zash Right.
  46. ralphm Zash: because I'm slow
  47. Tobias Dave Cridland, downgrade from TLS to non-TLS?
  48. ralphm Zash: and had a funeral yesterday
  49. Zash Tobias: Strip the starttls advertisment.
  50. Zash ralphm: Oh, sorry. No hurry.
  51. Dave Cridland ie, I connect to my server, and get my connection policy blob. Next day, I connect to my server, and it has no TLS, but my connection policy blob says my server always offers TLS, so I ditch the connection.
  52. Tobias right
  53. Tobias but shouldn't clients complain anyway if TLS is not available?
  54. Zash We could just never allow non-TLS if TLS succeeded once.
  55. Tobias Zash, right..or that
  56. Zash And never allow invalid certs if the cert was valid once
  57. Zash etc
  58. Dave Cridland Zash, There are operational issues there, I suspect.
  59. Tobias could completely life in the implementations
  60. Tobias without need of standard
  61. Zash Yeah
  62. Zash Something like HSTS would be an explicit approval of doing that.
  63. Zash I'm not sure we really need it
  64. Dave Cridland Zash, More importantly, that's a hand-waving exercise - there's no way to know if your clients support that, and there's enough kinks and choices that a pathway through to some kind of downgrade might be important.
  65. Dave Cridland For real entertainment, we could have a XMLSec signed document with the connection security policy in it, and then be able to access that via a number of methods. But hey.
  66. Kev iq:get after authentication.
  67. Kev I win.
  68. Tobias aren't you supposed to be holidaying? ;)
  69. Zash Having DANE records published also implies that tls should be supported.
  70. Dave Cridland I was thinking in terms of iq:get from other servers and such.
  71. Dave Cridland Zash, Yes, this is certainly true.
  72. Kev Tobias: Never reveal in public when someone's not at home.
  73. Kev Tobias: And yes, although I'm back home now.
  74. Tobias Kev, ah.oops.right..sry
  75. Dave Cridland Tobias, It's OK, I'm sure Kanchil keeps an eye on the place.
  76. Tobias Dave Cridland, sure
  77. waqas has joined
  78. Tobias cool...drag and drop invite worked for waqas :)
  79. waqas Hello
  80. Tobias waqas, we're just discussing security improvements to XMPP
  81. waqas has strong opinions on that...
  82. Tobias waqas, which are?
  83. waqas Well, there are multiple separate aspects of the XMPP network that are weak. Bad clients (cert verification issues, cipher suites, etc), bad server deployments (SSLv2, bad cipher suites, PLAIN over unencrypted), server software defaults, etc
  84. waqas Then we have the separate class of security missing entirely from XMPP: encrypted jingle, e2e encryption, etc
  85. waqas Some of this requires activism, while some requires standards work
  86. Tobias bad ciphers and so probably falls into the activism area
  87. waqas Something like a validation service might help the server deployment side of things a lot
  88. Kev I think an Informational XEP here might be in order.
  89. waqas I'm +1 to that
  90. Tobias also i'd interesting to have some kind of MITM protection, i.e. if your usual cert is suddenly replaced by some other strange cert (i know it sounds vague)
  91. waqas It would also be nice if support for that XEP was required to get on the xmpp.net server list :)
  92. Tobias waqas, the xmpp.net list is a whole other topic...it doesn't seem to really scale
  93. Kev Tobias: I think an Informational for that is interesting too.
  94. waqas A validation service would help it scale to some degree. For better or worse, a lot of public XMPP deployments want to be on that. If the XSF can use that to upgrade the security of the XMPP network, that's a good thing IMO.
  95. ralphm another thing is that server implementations generally don't alert admins about bad certs
  96. Tobias Kev, what would be the rough gist of it?
  97. Kev Tobias: Sounds too much like work for a holiday :p
  98. Dave Cridland You've seen PSA's new I-D on XMPP and TLS?
  99. Kev Only that it exists.
  100. Tobias Kev :P
  101. Kev That covers cyphers, but not pinning stuffs, I think?
  102. Dave Cridland Right, it addresses much of waqas's easily addressable concerns.
  103. Kev I'll read it at some point :)
  104. waqas It seems like a good start
  105. Dave Cridland waqas, But yes, we should require claims of conformance to various specifications to be listed, I think.
  106. waqas Does anyone know how bad compatibility issues are with dropping SSLv3? Is most everything supporting TLS1.0 these days?
  107. Dave Cridland waqas, Most of the figures I've seen relate to browsers. I don't know about XMPP, I suspect we're generally TLSv1.0 and up.
  108. ralphm I also want to note that SSLv3 is entirely not supported, spec-wise.
  109. ralphm and never has been for XMPP 1.0
  110. waqas I assume most of you have read xnyhps's (Adium dev) recent posts regarding client cipher suites?
  111. Dave Cridland I've not. Link?
  112. Zash https://blog.thijsalkema.de/blog/2013/08/26/the-state-of-tls-on-xmpp-1/
  113. waqas The three "State of XMPP TLS" posts: https://blog.thijsalkema.de/
  114. waqas He has been gathering data on what cipher suites, etc different actual clients support
  115. waqas This sort of information can feed directly into client+server software configuration defaults, and given most deployments don't bother changing defaults, would help improve security
  116. waqas It also gives data required for pestering software vendors to fix their stuff
  117. waqas Also, jabber.org might be able to do a whole lot in getting deployments updated. If jabber.org disabled certain bad things, e.g., SSLv3 or export ciphers or required TLS crypto for everyone except Google (can the software pull that off?) or Google went away, etc, other deployments of both servers and clients would simply be forced to follow.
  118. waqas Few compatibility concerns in XMPP land has been as strong as the desire to stay compatible with jabber.org, and this is a fact which can be used to force change
  119. waqas *have
  120. Dave Cridland waqas, I think M-Link's manuals are publi, and as such, I think I can safely say that TLS options in M-Link are global, and not tied to peer controls - TLS requirement and certificate pinning are at the peer level, though.
  121. ralphm waqas: the problem with whitelisting GTalk is that you have to do it based on the resolved host, because there are so many domains there.
  122. Tobias right...or delegating new user registrations to servers which have decent security
  123. ralphm I think even Prosody doesn't support it in that way.
  124. waqas Yep, which is bad, but such a thing would be strictly better than what we currently have
  125. Dave Cridland ralphm, Ah, good point. So jabber.org couldn't simply whitelist Google; it does these things by name.
  126. waqas And I freely admit it's a bit of wishful thinking, which while possible, isn't implemented anywhere
  127. Zash ralphm: Plugin could do that ;)
  128. Dave Cridland Of course, this is one thing we all thought we could do with Google dropping S2S, except they kind of haven't.
  129. waqas And I suspect they might not for a long time
  130. waqas Heck they might decide to never drop it, and we'll have this insecure s2s situation forever
  131. ralphm Zash: of course, but the existing config support for that only works on domains
  132. jabberjocke has joined
  133. waqas I notice mention of HSTS in the room history. That's a nice-to-have thing. We don't have a spec like that, but a client notifying me when it connects to a server and has stuff changed (different cert, but more importantly: weaker security), would be useful to me at least
  134. waqas I'm not entirely clear on what this discussion is. Part of the council meeting? Just random discussion after it? :)
  135. Zash waqas: Do you think we need a HSTS-ish spec?
  136. Zash spec/protocol
  137. Dave Cridland waqas, Random discussion because we'd not left since yesterday.
  138. waqas Could the current HTTP-ish HSTS spec be used in some way? I don't recall what it looked like. Was it just an HTTP header? If so, a stream feature would be all the spec work required?
  139. Zash waqas: Header saying don't accept plain connections for N time
  140. ralphm so, everyone here, if you are planning on going to the XMPP Summit in Portland, and haven't signed up in the wiki yet: WHY NOT!
  141. Zash ralphm: Expensive and far away.
  142. Dave Cridland And if you're not coming, I think the six of us who are will find a really good bar and whole up for the evening.
  143. Dave Cridland Hole up, even.
  144. waqas Dave Cridland: MattJ and I don't drink… we'll just be staring at you the whole time
  145. Tobias waqas, +1 on that
  146. ralphm Zash: to be sure, I wasn't asking why people were not planning to come.
  147. ralphm Zash: it appears that we have a bunch of people that are going to, but we don't know about them
  148. Tobias Zash, was fosdem acceptable regarding the costs?
  149. Dave Cridland waqas, You're coming?
  150. waqas Dave Cridland: Well, I'm in the US, and have a realtimeconf ticket, so: probably
  151. Zash Tobias: I think so. But I skimped on accomodation costs by staying with friends.
  152. Tobias waqas, US must have a nice visa process ^^
  153. Dave Cridland Tobias, Yeah, but he has to get through TSA with that name...
  154. waqas Tobias: Surprisingly easier than Belgium. It was a lot more well-defined.
  155. Tobias Dave Cridland, he could just put a turban on and would be fine
  156. waqas And the TSA was being weird both times I arrived. The security seemed to be missing entirely at JFK.
  157. Dave Cridland JFK can be hit and miss. It's usually horribly crowded for me, though hey seem to be rebuilding it.
  158. ralphm I never went there
  159. waqas No scanners, no questioning, no baggage checks (I literally could have walked out with anyone's luggage both times), I saw no real evidence of the TSA
  160. ralphm AMS->PDX FTW
  161. Tobias PDX?
  162. ralphm Tobias: Portland, OR
  163. Tobias ahh
  164. Dave Cridland ralphm, I'll be CWL->AMS->???->DCA, and DCA->PDX, then PDX->AMS->CWL.
  165. m&m oy
  166. ralphm Dave Cridland: AMS->PDX->SFO->AMS for me
  167. ralphm m&m: hi
  168. m&m waves
  169. ralphm waqas: go sign up at http://wiki.xmpp.org/web/Summit_14
  170. Dave Cridland ralphm, Right; I can't fly into DCA from outside the US, and refuse to fly into Dulles, so...
  171. Kanchil ralphm: http://wiki.xmpp.org/web/Summit_14: Summit 14 - XMPP Wiki
  172. waqas Well, I need to check out of this hotel, was just about to leave when Tobias invited me here, so I'll be on a train for an hour. Hopefully my input was useful in some way :)
  173. Dave Cridland waqas, Sign up first.
  174. waqas Done
  175. ralphm waqas: what Dave Cridland said, because we can then maybe still do a hotel package deal
  176. waqas Ah good, I was wondering about what to do about a hotel
  177. Dave Cridland That's now 6 awesome people. And me.
  178. Dave Cridland waits for someone else to tell him he's awesome too.
  179. Kev I won't be able to make it.
  180. waqas I'm running off now folks
  181. waqas waves
  182. Kev Bibi.
  183. waqas has left
  184. ralphm Kev: good save regarding Dave's ponderance
  185. Dave Cridland Yeah, thanks guys.
  186. Zash Dave Cridland: You're awesome.
  187. ralphm For what it is worth, I did include you in my oob assertion.
  188. m&m I'm going to be missing out myself
  189. m&m would have been good to hang out with such awesome people
  190. m&m and Dave
  191. jabberjocke has left
  192. Zash has left
  193. stpeter has joined
  194. stpeter has left
  195. stpeter has joined
  196. ralphm hibyehi stpeter
  197. Tobias has joined
  198. waqas has joined
  199. Zash has joined
  200. Tobias has joined
  201. Neustradamus has joined
  202. Dave Cridland has left
  203. Lance has joined
  204. jabberjocke has joined
  205. m&m has left
  206. m&m has joined
  207. Lance has left
  208. stpeter has left
  209. m&m has left
  210. Tobias has left
  211. Tobias has joined
  212. Zash has joined
  213. m&m has joined
  214. m&m has left
  215. m&m has joined
  216. Lance has joined
  217. Lance has left
  218. Lance has joined
  219. Tobias has left
  220. Tobias has joined
  221. Lance has joined
  222. m&m has left
  223. m&m has joined
  224. m&m has left
  225. tato has joined
  226. stpeter has joined
  227. m&m has joined
  228. tato has left
  229. tato has joined
  230. m&m has left
  231. Lance has left
  232. Lance has joined
  233. Lance has left