XMPP Council - 2017-02-22

  1. Zash has left

  2. Kev has left

  3. Lance has left

  4. Kev has left

  5. Lance has joined

  6. Lance has left

  7. Tobias has joined

  8. Tobias has joined

  9. Kev has left

  10. SamWhited has joined

  11. jere has joined

  12. SamWhited has joined

  13. daniel has left

  14. daniel has joined

  15. Kev has left

  16. Kev has left

  17. jayaura has left

  18. Kev has left

  19. Kev has left

  20. Zash has joined

  21. peter has left

  22. Flow has joined

  23. Flow has left

  24. Kev has left

  25. SamWhited has left

  26. Kev has left

  27. Kev has left

  28. jayaura has joined

  29. jcbrand has joined

  30. Kev has left

  31. ralphm has left

  32. jayaura has joined

  33. Kev has left

  34. jayaura has joined

  35. Flow has joined

  36. Kev has left

  37. jere has joined

  38. jere has left

  39. jere has joined

  40. Dave Cridland has left

  41. Dave Cridland has joined

  42. Kev has left

  43. jayaura has joined

  44. jayaura has joined

  45. Dave Cridland has left

  46. jayaura has joined

  47. Dave Cridland has left

  48. Kev has left

  49. jayaura has joined

  50. jere has left

  51. jere has joined

  52. Kev has left

  53. Zash has left

  54. Kev has left

  55. Kev has left

  56. daniel has left

  57. daniel has joined

  58. moparisthebest has joined

  59. jere has joined

  60. Tobias has left

  61. jere has joined

  62. Flow has joined

  63. jayaura has joined

  64. jayaura has joined

  65. ralphm has joined

  66. jcbrand has left

  67. Kev has left

  68. SouL has left

  69. Tobias

    moparisthebest, didn't you plan an update on https://xmpp.org/extensions/xep-0368.html security considerations after last week's discussions with SamWhited?

  70. moparisthebest

    Tobias, I updated it

  71. Tobias

    so it's just the editor that hasn't processed it yet, ok

  72. moparisthebest

    he wanted the description updated, and I changed something else too, I think it's good to go

  73. moparisthebest

    I think he did? I'll check

  74. moparisthebest

    yea that's the latest version

  75. Tobias


  76. SamWhited

    I thought I merged… refresh?

  77. Link Mauve


  78. Tobias

    yeah..seems it's the latest version

  79. Tobias

    ah..seems it's about time

  80. Tobias

    1) Roll call

  81. daniel


  82. SamWhited nods

  83. Dave Cridland


  84. Link Mauve

    Here too.

  85. Tobias


  86. Tobias

    2) Minute taker

  87. Tobias

    seems jc isn't here, so we need a volunteer

  88. daniel

    i can do it

  89. Tobias


  90. Tobias

    3) Outstanding votes

  91. Tobias

    https://trello.com/b/ww7zWMlI/xmpp-council-agenda there are 2 ProtoXEPs and 2 other voting issues on the trello, please see recent minute notes and reply on list to vote

  92. Dave Cridland

    I've a few there.

  93. Tobias

    4) Clarify CSI and Carbons state after SM resumption https://github.com/xsf/xeps/pull/402

  94. Tobias

    Sam added this earlier this month, Flow closed his PR and opened indepenent PRs instead. Please take a look and reply feedback in the PRs.

  95. Tobias

    5) The Last Call for XEP-0333: Chat Markers ended, daniel is taking maintainership and will probably send in an update sometime so we can vote on advancing it

  96. SamWhited

    If daniel plans on making more changes, I will extend the LC by another week.

  97. Tobias

    more changes? haven't seen changes since the LC was issued

  98. SamWhited

    s/more changes/changes/

  99. Tobias


  100. Tobias

    6) Vote on advancing XEP-0368: SRV records for XMPP over TLS, specifically Version 0.1.2, to Draft

  101. Tobias

    I'll vote on list

  102. daniel


  103. SamWhited

    I still don't like the direct TLS definition text, but that's an editorial change that can be made during draft

  104. SamWhited

    so +1

  105. daniel

    re extending the last call for xep333. please do. i will make changes in the next wee

  106. Tobias

    Dave Cridland, Link Mauve ?

  107. Link Mauve

    Wasn’t there a pending PR to fix the direct TLS definition?

  108. Link Mauve

    Apparently not.

  109. Link Mauve

    Anyway, will vote on list.

  110. Dave Cridland

    I think '368 is ready to go Draft now.

  111. Tobias

    that's probably supposed to be at least a +0

  112. Tobias


  113. Dave Cridland


  114. Tobias


  115. Dave Cridland

    FTR, I'm sure there's further editorial fixes, but the technical side seems solid.

  116. Tobias

    7) Date of next

  117. Tobias

    I'm probably traveling next Wednesday around this time

  118. daniel

    should we do tuesday?

  119. daniel

    same time?

  120. Link Mauve

    I’m ok with Tuesday.

  121. SamWhited


  122. Tobias

    that could work better for me, yeah

  123. Tobias

    does that work for you, Dave Cridland?

  124. ralphm has left

  125. Dave Cridland

    I think so.

  126. Tobias

    great..that would be 2017-02-28 16:00:00 UTC then

  127. Tobias

    8) AOB

  128. SamWhited


  129. Tobias


  130. SamWhited

    XEP-0233, 0280, 0334, 0352 had their LCs end today. One of them has a pending PR (0280), otherwise do we want to do anything about them?

  131. Tobias

    probably see what the feedback was on them, if there was positive feedback indicating that they are fine and no changes are required, we can vote on them next week

  132. Tobias

    if the feedback indicates changes are required, they should stay proposed until we receive an update on the XEP

  133. daniel

    334 and 352 are probably good to go

  134. daniel

    but we can vote on that next time

  135. daniel

    i think with these widely deployed xeps no feedback is good feedback

  136. SamWhited

    334 I'm a bit torn about, but I agree with 352

  137. SamWhited

    anyways, next week. In the mean time should I extend the LC or move them back to experimental?

  138. Tobias

    i'd request to extend the LC of XEP-0233 and i'll bug someone who implemented it to respond with feedback on the list

  139. Kev

    FWIW, I don't think that's true, 'no feedback' is generally a sign of no interest in XEPs, which implies they've probably not seen sufficient review.

  140. Kev

    (Not saying that's the case with 334/352 necessarily, but as a general point)

  141. daniel

    Kev, i was specifically talking about those day. as they seem to be used and implemented

  142. daniel


  143. Tobias

    yup...and we should try bugging people having implemented those...even if they have little time they could simply reply with a mail answering the questions with a short Yes/No.

  144. Link Mauve

    Tobias, that sounds sensible.

  145. daniel


  146. Tobias

    any other AOB?

  147. SamWhited

    Sounds reasonable; in that case I'll extend the LCs again.

  148. Tobias

    SamWhited, sounds sensible

  149. Tobias

    doesn't look like it

  150. Tobias bangs the gavel

  151. Tobias

    thanks everyone

  152. Link Mauve

    Thank you!

  153. Tobias

    thank you daniel for writing up meeting minutes

  154. moparisthebest

    note with 368 I made a somewhat major change with the last version

  155. jere has joined

  156. moparisthebest

    SamWhited, pointed out 3.1 had no proper SHOULD/MUST etc language

  157. moparisthebest

    in my mind that was always a MUST (mixing priorities of records), but he and ralphm convinced me it should be a SHOULD

  158. moparisthebest

    so maybe it was only a major change in my mind :)

  159. Tobias

    will give the XEP a total reread this evening then :) luckily it's not that big

  160. moparisthebest

    yea and it works the same both ways, the server op can't tell if you mixed priorities or some ports were blocked

  161. moparisthebest

    so in the grand scheme of things, no big deal

  162. ralphm has left

  163. jayaura has joined

  164. Dave Cridland

    So it might be that there exist circumstances to not mix priorities properly, and it'll still interop? Feels like a SHOULD is OK here.

  165. jcbrand has joined

  166. Dave Cridland

    moparisthebest, What were the cases ralphm and SamWhited were unable to mix priorities?

  167. moparisthebest

    Dave Cridland, ralphm pointed to the python twisted lib that connected to SRV records and how it'd be hard to mix them, but easy to try xmpps-client first then xmpp-client second

  168. moparisthebest

    which is fair, and like you said doesn't affect interop, and moreover is invisible to the server

  169. Zash

    moparisthebest: I also believe that'd be easier to implement.

  170. moparisthebest


  171. Zash

    Keeping track of 'this srv entry is with tls/with starttls' seems like a recipe for messing up

  172. Dave Cridland

    Zash, I found it easy enough, and RFC 6168 is the same, so it's not uncommon.

  173. moparisthebest

    it was easy in conversations

  174. moparisthebest

    you already have to keep an object with 'target' and 'port', throwing 'directTls' in there is trivial?

  175. Dave Cridland

    That's basically what I did in Metre.

  176. Dave Cridland

    It treats a _xmpps-server._tcp record as if it were a _xmpp-server._tcp record with an extra field of "tls=true".

  177. Zash

    I may have done somesuch for DANE

  178. moparisthebest

    conversations code starts about here: https://github.com/siacs/Conversations/blob/master/src/main/java/eu/siacs/conversations/utils/DNSHelper.java#L184

  179. moparisthebest

    and yea I think you'd do DANE the same way, store the key hash on the same object

  180. moparisthebest

    I think, implementing dnssec+dane is fairly high on my priorities as a next patch for conversations

  181. Dave Cridland

    moparisthebest, See the minidns work that the XSF had s a GSoC project a couple of years back - should work fine. Smack uses it already.

  182. Dave Cridland

    moparisthebest, But just do DNSSEC+RFC 6125 names to beging with.

  183. moparisthebest

    yea Dave Cridland conversations already uses minidns, so I think it's basically just writing a bit of code

  184. moparisthebest

    so that brings up an interesting point, DANE can pin certs, public keys, and anywhere in the chain, but the RFC recommends implementations for a specific protocol pick one way and stick with it

  185. moparisthebest

    like for SMTP they just use public key pinning on the end device and that's all that is supported

  186. jayaura has joined

  187. Lance has joined

  188. moparisthebest

    sorry had to run off, but is there a standard like that for DANE with xmpp?

  189. moparisthebest

    or can/should we make one?

  190. Dave Cridland

    DANE-SRV is as close as we get. But I'm happy supporting all forms - I've seen use-cases for all of them.

  191. moparisthebest

    I despise certificate pinning personally hehe

  192. moparisthebest

    pinning the end devices public key is the only way to go in my opinion

  193. Zash has joined

  194. SamWhited

    Dave Cridland: I *can* mix priorities, I just don't want too. I'm going to try connecting and starting TLS and connecting and starting a plain stream at the same time probably; if TLS works, it wins, otherwise start using the plain stream that was already being negotiated.

  195. Kev has left

  196. moparisthebest

    attempting simultaneous connections sounds , not good for some reason

  197. moparisthebest

    do you do that now with existing SRV records? attempt them all at once and see which one wins?

  198. SamWhited

    moparisthebest: I'm not doing it for each record, just for each type of record (xmpp vs. xmpps); weights and priorities are still used within those records.

  199. SamWhited

    However, yes, if you have a few servers with identical weights and priorities, I would like to connect to all of them and use whichever one wins.

  200. SamWhited

    (and then if that fails, fall back to the next set of weights/priorities)

  201. moparisthebest

    what's the difference? the server op mixed priorities when they defined them

  202. moparisthebest

    I mean none of this really matters, you can do it however you like and interop and everything will work perfectly

  203. SamWhited

    If the server op made plain a higher priority than TLS, I'm ignoring it. That's basically the only difference.

  204. moparisthebest

    just seems strange, I assumed people that wouldn't mix them would just try xmpps- first, then xmpp-

  205. Kev has left

  206. SamWhited

    That's what I'm doing; doing it at the same time is just an optimization (if we can't do xmpps, we just fallback to the connection that's already started)

  207. moparisthebest

    yea but in doing both at the same time it's slower than just doing the first would be

  208. moparisthebest

    if bandwidth is constrained or anything

  209. SamWhited

    maybe, but I really doubt even the slowest connections are *that* slow (unless you're operating of HFR or something)

  210. Kev

    And no-one would do that, right? :)

  211. SamWhited

    Heh, I'm aware that it exists, I'm just not writing a library that aims to target every single use case (although, this will probably be an option when you configure the session, so it will probably support not doing it this way too, haven't figured the API out yet though)

  212. jayaura has joined

  213. Dave Cridland

    I was wondering about happy-eyeballs across multiple SRV records.

  214. Kev

    I think I've suggested before that happy-eyeballs across multiple same-priority records is sensible.

  215. moparisthebest

    how many domains have enough servers where it'd make a difference?

  216. moparisthebest

    that's a genuine question I really do not have any idea :)

  217. ralphm has left

  218. SamWhited

    I'm not sure; probably not many, but it's also not hard to do or anything, so I'm not sure that it matters. ¯\_(ツ)_/¯

  219. jayaura has joined

  220. moparisthebest

    it just kind of smells of premature optimization, multi-threaded code where connections are racing and one wins doesn't sound like the simplest thing to implement, especially if 99% of cases have 1 server anyway

  221. SamWhited

    Nah, I've already done it, it was trivial.

  222. moparisthebest

    probably depends a lot on the language too :)

  223. moparisthebest

    what are you using? go still?

  224. SamWhited

    Yah, Go (which indeed is the reason why it was trivial)

  225. moparisthebest

    is that code open source anywhere? I'd like to have a look

  226. SamWhited

    I just need to add it to my XMPP library and also add the XMPP/XMPPS version (although that's not a race, that's waiting on XMPPS and just pre-negotiating XMPP in case XMPPS fails)

  227. moparisthebest

    yea I was thinking about how to implement it in java, but I'm not sure I'd call it trivial

  228. SamWhited

    Nothing is trivial in Java… everything is harder than you expect it to be.

  229. SamWhited

    Or maybe that's just me.

  230. moparisthebest

    I wouldn't go that far :) but yea

  231. Zash has joined

  232. Kev has left

  233. Kev has left

  234. Kev has joined

  235. Kev has left

  236. Zash has left

  237. Lance has left

  238. jere has left

  239. Dave Cridland has left

  240. Dave Cridland has left

  241. Zash has left

  242. jcbrand has left

  243. Kev has joined

  244. Kev has left

  245. jere has joined

  246. Zash has joined

  247. Dave Cridland has left

  248. Dave Cridland has left

  249. Tobias has left

  250. Dave Cridland has left

  251. Dave Cridland has left

  252. Tobias has left

  253. Zash has joined

  254. jcbrand has joined

  255. Tobias has joined

  256. Zash has joined

  257. peter has joined

  258. Lance has joined

  259. Kev has joined

  260. Kev has left

  261. Kev has joined

  262. jcbrand has left

  263. Lance has left

  264. Lance has left

  265. Kev has left

  266. moparisthebest has joined

  267. Lance has left

  268. Lance has left

  269. peter has left

  270. Kev has joined

  271. Zash has joined

  272. Kev has left

  273. daniel has left

  274. jayaura has left

  275. jayaura has joined

  276. Kev has left

  277. daniel has left