XMPP Council - 2012-04-04

  1. linuxwolf has left
  2. Tobias has joined
  3. Tobias has left
  4. fippo has joined
  5. Tobias has joined
  6. Tobias has left
  7. Tobias has joined
  8. linuxwolf has joined
  9. linuxwolf has left
  10. linuxwolf has joined
  11. Tobias has joined
  12. Tobias has joined
  13. MattJ has joined
  14. linuxwolf meeting in one more hour (ish)?
  15. Kev Nope, now.
  16. Kev I suck.
  17. Kev Thanks for the poke
  18. linuxwolf heh
  19. linuxwolf no worries
  20. linuxwolf is still not sure which timezone he's hin
  21. Kev I'm in GSoC time.
  22. linuxwolf (-:
  23. Kev But anyway.
  24. Kev 1) Roll call.
  25. linuxwolf presente
  26. Kev MattJ / Tobias: Highlight.
  27. Tobias present
  28. MattJ Boo
  29. MattJ gift
  30. linuxwolf offering?
  31. Kev Righty
  32. Kev 2) XMPP WG report.
  33. Kev linuxwolf: You fancy giving one? :)
  34. linuxwolf sure
  35. linuxwolf The WG meeting in Paris, one week back
  36. linuxwolf major topics are end-to-end encryption, domain-name-assertions, and i18n
  37. Tobias roughly the same topics as 5 years ago it seems :)
  38. linuxwolf there is a draft for a new proposal to e2e, which puts key management into a protocol, and is trying to re-use the work from JOSE (JSON Object Signing and Encrypting)
  39. linuxwolf Tobias: basically (-:
  40. MattJ I finally know what JOSE is
  41. linuxwolf (-:
  42. Kev linuxwolf: So long as it doesn't need us to rewrite XMPP in JSON.
  43. linuxwolf no!
  44. linuxwolf the proposal has been received favorable reviews to date
  45. linuxwolf the crypto bits are encoded with some sprinkling of JSON, but the XMPP stuff is still XML
  46. Kev OK.
  47. linuxwolf it was either that or ASN.1
  48. linuxwolf no one born after 1970 wants to use ASN.1
  49. Tobias wheeee..ASN.1 :D
  50. MattJ :)
  51. Kev Right.
  52. linuxwolf if you're interested: http://tools.ietf.org/html/draft-miller-xmpp-e2e
  53. linuxwolf there'll be an update to that sometime this month (-:
  54. Kev Ta. I'll have a read at some point (not right now).
  55. linuxwolf DNA ...
  56. linuxwolf so, after floundering about with non-discussion ...
  57. linuxwolf … an approach is starting to form around a layered approach
  58. linuxwolf 1) determine alternate trust algorithms for certificates
  59. linuxwolf 2) use stream:stream headers and/or dialback for asserting names (then use the afore mentioned prooftypes)
  60. linuxwolf there's been discussion for two alternatives over PKIX: https/.well-known and DANE
  61. linuxwolf DANE is a DNS-based protocol, essentially you get the target cert, signed indirectly with DNSSEC
  62. linuxwolf the TLSA RR is signed, but the cert can be almost anything: self-signed, ca-signed, trust-anchor, etc
  63. Tobias linuxwolf, alternatives? can't PKIX, https/.well-known and DANE co-exist?
  64. linuxwolf they can
  65. Tobias and HTTPS's S is based on what, PKIX?
  66. linuxwolf and a server (or client) will likely need to implement all three
  67. linuxwolf the HTTPS/.well-known is simply the target certificate (or maybe also a trust-anchor) at a specific path through HTTPS
  68. linuxwolf the trust established if you can trust the HTTPS connection
  69. Tobias PKIX and DANE are likely to be implemented in TLS libraries in future, right?
  70. Kev Tobias: HTTPS:/.well-known is basically "Yes, we're not solving any problems, but we're saying they're not *our* problems, so that's fine".
  71. linuxwolf in all cases, the target cert would be the hosting services cert (e.g. talk.goole.com or webexconnect.com) but obtained from the target domain (e.g. example.com)
  72. linuxwolf PKIX is already implemented in OpenSSL
  73. Tobias linuxwolf, right...wrongly phrased
  74. linuxwolf DANE is likely to be implemented in some DNS libraries
  75. linuxwolf but just to get the cert
  76. Kev linuxwolf: *Some* of PKIX is in OpenSSL, right?
  77. linuxwolf you'll then feed that into, say, OpenSSL to complete validation
  78. Kev PKIX also includes revocation, doesn't it?
  79. linuxwolf Kev: it depends on what version of OpenSSL we're talking about
  80. linuxwolf it does
  81. Kev And OpenSSL doesn't do revocation checks for you.
  82. linuxwolf it can do some
  83. Kev Does it?
  84. Tobias k...and the HTTPS way will probably always need to implemented directly by XMPP client/server devs
  85. linuxwolf 1.0 can process a CRL chain, if it's local
  86. linuxwolf Tobias: most likely
  87. linuxwolf as I see it: HTTPS would be implemented "now", and DANE would come later
  88. Tobias linuxwolf, is DANE so far away *now*?
  89. linuxwolf long-term, DANE is probably the better technical approach, but it's not exactly deployable yet
  90. linuxwolf it depends on who you ask
  91. Tobias yeah...i've asked my ISP and he said ask again in a month ^^
  92. linuxwolf there are more and more DNS resolvers and nameservers supporting DNSSEC, but only for the common TLDs
  93. Tobias right
  94. linuxwolf outside of .com/org/net, it's not available
  95. linuxwolf DANE has not finished IESG Last Call, so there's a lot of people holding off on implementations
  96. Tobias but requireing HTTPS support for XMPP clients/servers
  97. linuxwolf /shrug
  98. linuxwolf HTTPS implementations are everywhere, and if a server supports BOSH, it already supports HTTP
  99. linuxwolf adding HTTPS is not *that* much more work, unless you did everything by hand
  100. Tobias but then again there are a lot (maybe even well tested) ready to use implementations for it
  101. linuxwolf exactly
  102. MattJ If a server supports BOSH it supports being a server, not a client
  103. linuxwolf plus, a lot of clients end up with HTTP libraries for things like updating and grabbing images and whatnot
  104. Kev I think it's a much more nefarious problem than that.
  105. MattJ but *shrug*, Prosody does both already
  106. linuxwolf MattJ: true, but like I said there are lots and lots of HTTP libraries around
  107. Kev It's one thing "supporting HTTP", it's quite another getting this into the trust checking for the XMPP session.
  108. Kev But anyway.
  109. MattJ Is it really?
  110. linuxwolf Kev: well, gotta get there somehow
  111. MattJ Harder than anything else?
  112. MattJ The trust checking is going to change anyway
  113. linuxwolf right
  114. Kev MattJ: Harder than PKIX, which is already required, yeah :)
  115. linuxwolf PKIX isn't good enough already, so *something* needs to be done
  116. MattJ Right
  117. Tobias exactly
  118. Kev So, do you connect to the XMPP server, ask for the cert, then see it's not right, so go on to check over HTTPS?
  119. linuxwolf both DANE and HTTPS are essentially "does this cert match", without the need to go through the nitty-gritty subject
  120. Kev If both certs are 'bad', but behind the HTTPS cert is the .well-known for the XMPP server, do you present the HTTP stuff to the user and ask them to trust the HTTPS? etc.
  121. linuxwolf Kev: that's roughly what I was thinking
  122. Kev I'm not saying these aren't resolvable problems.
  123. Kev I *am* saying this is a lot more unpleasant at the edges than "Well, there are plenty of HTTPS libraries, so we just use those" makes it sound.
  124. MattJ Sure
  125. linuxwolf Kev: it's a detail that does need to get worked out, but frankly the HTTP people have done a lot more with it than anyone else
  126. Kev Right, probably.
  127. Kev So, moving on :)
  128. linuxwolf anyway, comments on the xmpp@ietf.org mailing list are most welcome
  129. linuxwolf the last one is i18n
  130. linuxwolf Precis is finishing up its definition of the framework, and stpeter has a draft for 6122bis based on that
  131. linuxwolf but, there are a lot of dragons to work out, and we're suggesting some sub-profiles for specific things, like MUC nicknames
  132. linuxwolf so a resourcepart would accept just about anything, but usage with MUC would be more restrictive
  133. linuxwolf some discussion on how one might go about enforcing and discovering such rules (which are seen as locale-specific) was thought about
  134. linuxwolf a lot of 6122bis is waiting on precis, which is progressing … albeit slower than others would like
  135. linuxwolf and I think that about sums up the actual meeting
  136. MattJ The "others" who don't like the speed aren't very vocal in helping resolve issues (afaics)
  137. linuxwolf there is a proposal from a group in Japan for alternatives to DNS SRV, and they'd like feedback on it
  138. MattJ Not that the issues are easy, but that's why it's slow
  139. linuxwolf MattJ: essentially
  140. linuxwolf well, that, and it's really a cultural problem we're attempting to solve with technology
  141. linuxwolf so there may not actually be a right way to do this anyway
  142. MattJ Indeed
  143. linuxwolf the precis meeting ended with "maybe we need a new area directorate for internationalization"
  144. Tobias heh
  145. linuxwolf yeah
  146. linuxwolf oh, one last point on DNA: there is no current draft yet, but there's three of us working on one, once we get back to work from IETF (-:
  147. linuxwolf so be on the lookout for that, if you care about it
  148. Kev Lovely.
  149. Kev So that's Paris covered?
  150. linuxwolf most people, smarter people, take time off after these
  151. linuxwolf yes
  152. Kev 3) Date of next meeting - same time next week?
  153. Tobias wfm
  154. linuxwolf wfm
  155. MattJ wfm
  156. Kev 4) Request from chair
  157. Kev Can someone else minute this please?
  158. linuxwolf will do
  159. Kev Thanks verym uch.
  160. Kev 5) AOB?
  161. MattJ None here
  162. linuxwolf I'll have them out by tomorrow
  163. linuxwolf nothing more from me
  164. Tobias neither here
  165. Kev Marvellous.
  166. Kev Thanks all.
  167. Kev meeting over gavel bangs.
  168. linuxwolf five minutes over (-:
  169. MattJ :)
  170. linuxwolf goes off to next meeting … which is probably already over
  171. Kev Yeah, sorry.
  172. linuxwolf no, it's perfectly fine
  173. Kev Exactly 30 minutes, but I needed to be poked to start.
  174. linuxwolf fine with me anyway, I've already told the others I'm likely to miss on Wednesdays (-:
  175. Kev MattJ: MAM. We're almost certain to have someone working on it in Swift for GSoC - so a) Where's the spec and b) How's Prosody's support?
  176. MattJ a) the spec is either the one currently on matthewwild.co.uk, or the one I haven't finished yet to submit
  177. MattJ b) Prosody's support is for the one on matthewwild.co.uk, and I believe it is mostly complete, just inefficient (fine for developing with, not for production)
  178. MattJ Zash would know more, since he wrote it
  179. Kev How different is what you're submitting for XEPpification from what's on mw.co.uk?
  180. MattJ Not very
  181. MattJ pulls up matthewwild.co.uk's version
  182. Kev OK, cool.
  183. Kev We have to expect some change from Experimental->Draft anyway.
  184. MattJ Right, so everything there will work
  185. MattJ But I'm adding querying by id too
  186. Kev But if you'd rewritten it, targetting that doc wouldn't be much use.
  187. MattJ No, the basics there won't change
  188. Kev "Querying by id" -> "Get me everything since ID X"?
  189. MattJ Yes
  190. Kev Cool.
  191. MattJ I think I talked to you about this once upon a time
  192. Kev Yes, I said we needed it.
  193. MattJ I was trying to avoid giving messages unique ids
  194. MattJ But I agree it's a necessary evil
  195. MattJ One interesting open question...
  196. MattJ Is how the client knows the id of messages it sends
  197. MattJ We either solve it so that it does, or it downloads duplicates
  198. MattJ at some point
  199. MattJ I think this is most important for clients that have dual local-remote history implementations
  200. MattJ and since all clients with history do local at the moment... it's important to them
  201. MattJ Everything else is simple, but I can't dream up a clean solution to this
  202. MattJ I was going to leave it open when I submit the spec, and see if anyone on the list has bright ideas
  203. Kev MattJ: Well, there are beautiful solutions for it that you don't want to consider :)
  204. MattJ Such as?
  205. Kev Like just redownloading all messages and ignoring your 'natural' history in favour of what's in MAM.
  206. MattJ Sure, that's one solution (no solution at all)
  207. MattJ It just feels like a waste of time to me to re-download messages it already has
  208. Kev Of course it is :)
  209. Kev But, I think we can solve this.
  210. Kev Or, rather, not knowing the id of your sent messages isn't the biggest problem here.
  211. MattJ What do you think is?
  212. Kev I'm assuming that the case we're trying to solve here is "I want to use MAM to get a full local history cache, given that I have already received all my this-resource messages"
  213. MattJ Indeed
  214. Kev And in this case, the big problem is 'filling in' the same history period for which you have a partial history.
  215. MattJ Mmm
  216. Kev Now, possibly the thing to do here is to always use carbons.
  217. Kev That is "If you are going to want a complete local history cache, always use carbons.".
  218. Kev That way you can sync from $LAST_ID -> $NOW when you log in, get carbons of everything from then on, and record the last received message id when you log out. Or even have the server send you the last MAM id for a message you've received when you close the stream.
  219. MattJ Indeed
  220. MattJ What about messages you send? Which carbons doesn't provide atm afaik
  221. Kev It should.
  222. Kev linuxwolf: Ping.
  223. Kev There's not so much point using carbons to get half of every conversation other than the one for the current session :)
  224. linuxwolf ??
  225. linuxwolf IIRC, the original thinking was if a specific resource is sending the message, it doesn't need a carbon of it
  226. linuxwolf how about I change § 3.6 to: Carbons clients want to have copies of messages going in /both/ directions for all resources associated with the same user. To that end, messages of type "chat" that are sent from any resource MUST be copied by the sending server to each of the resources that have enabled Carbons.
  227. Kev Do you currently get a copy of every message sent from another resource?
  228. Kev I thought $OTHER_MATT was implying that you didn't (I thought you did).
  229. Kev This is what you need. I don't think you need a duplication of your own outgoings.
  230. MattJ No, sorry, I wasn't implying that
  231. MattJ When I said "you" I meant the current resource
  232. Kev I don't think you need that, do you?
  233. linuxwolf the current text forwards a <sent/> carbon to every resource OTHER THAN the sending resource
  234. linuxwolf I can see going either way
  235. Kev linuxwolf: Thanks - that's all I think is needed, but Matt might know otherwise.
  236. linuxwolf forwarding to all sending resources makes it more MUC-like
  237. Kev It does. It also potentially makes it *slightly* nicer for local history caching.
  238. linuxwolf that's what I was thinking
  239. Kev But it's pretty slight, I think, and the bandwidth cost isn't insignificant.
  240. linuxwolf true
  241. linuxwolf then again, if you're mobile, you're radio is already at full because you just sent something (-:
  242. linuxwolf and if compression is enabled, how much is that cost really?
  243. linuxwolf just playing devil's advocate here … I'm fine with it as-is, or changing it to every … I don't really care
  244. Kev Right.
  245. Kev I'm happy with as-is, at the moment. I don't think it hurts MAM.
  246. Kev I think having a MAM server send you a "Your last received id is" when you log out would probably be a better solution, if a solution is needed (I'm not convinced it is).
  247. MattJ So you think clients should drop local history?
  248. Kev I don't think I'm saying that.
  249. Kev Although I could be wrong :)
  250. Kev I think I'm saying that MAM+Carbons is sufficient already to get a complete local cache.
  251. Kev Or even a local cache where it is incomplete, but the gaps are known.
  252. Kev (And thus could be filled when the user wants history)
  253. fippo has left
  254. linuxwolf has left
  255. Tobias has left