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


  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


  26. Kev

    MattJ / Tobias: Highlight.

  27. Tobias


  28. MattJ


  29. MattJ


  30. linuxwolf


  31. Kev


  32. Kev

    2) XMPP WG report.

  33. Kev

    linuxwolf: You fancy giving one? :)

  34. linuxwolf


  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


  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


  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


  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


  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


  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


  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


  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


  117. Tobias


  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


  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


  143. linuxwolf

    the precis meeting ended with "maybe we need a new area directorate for internationalization"

  144. Tobias


  145. linuxwolf


  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


  149. Kev

    So that's Paris covered?

  150. linuxwolf

    most people, smarter people, take time off after these

  151. linuxwolf


  152. Kev

    3) Date of next meeting - same time next week?

  153. Tobias


  154. linuxwolf


  155. MattJ


  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


  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


  190. Kev


  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


  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


  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


  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


  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


  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