XMPP Council - 2017-10-11

  1. jere has joined

  2. pep. has left

  3. Tobias has joined

  4. Tobias has joined

  5. daniel has joined

  6. ralphm has left

  7. moparisthebest has joined

  8. daniel has left

  9. Zash has left

  10. moparisthebest has left

  11. daniel has joined

  12. SamWhited has left

  13. Ge0rG has left

  14. Ge0rG has joined

  15. SamWhited has left

  16. Flow has joined

  17. Flow has left

  18. ralphm has left

  19. daniel has left

  20. daniel has joined

  21. jere has left

  22. jere has joined

  23. ralphm has left

  24. jere has left

  25. ralphm has left

  26. ralphm has left

  27. Flow has joined

  28. ralphm has left

  29. Flow has left

  30. Flow has joined

  31. Flow has left

  32. Flow has joined

  33. Flow has left

  34. ralphm has joined

  35. Flow has joined

  36. Flow has left

  37. Flow has joined

  38. ralphm has left

  39. ralphm has left

  40. ralphm has joined

  41. ralphm has left

  42. ralphm has joined

  43. ralphm has left

  44. Kev has left

  45. Kev has left

  46. ralphm has left

  47. ralphm has left

  48. Flow has left

  49. Flow has joined

  50. ralphm has left

  51. jere has joined

  52. Flow has joined

  53. Flow has joined

  54. ralphm has joined

  55. jere has left

  56. jere has joined

  57. Link Mauve

    Hi, I’m ill today so I won’t be here, good night. \o_

  58. Tobias

    get well

  59. ralphm has joined

  60. ralphm has left

  61. moparisthebest has joined

  62. daniel has left

  63. ralphm has left

  64. Flow has left

  65. Flow has joined

  66. ralphm has left

  67. Tobias


  68. Tobias

    1) Roll call

  69. SamWhited


  70. daniel


  71. Tobias

    Link Mauve is excused as he's ill

  72. Tobias

    have pinged dave in another channel

  73. Tobias

    2) Minute taker

  74. Tobias

    I can take minutes if there's no other volunteer

  75. daniel

    Please do. I'm traveling. Will do the minutes when I get back

  76. Tobias


  77. Tobias

    3) General reminder to vote on things, see pending votes column in trello https://trello.com/b/ww7zWMlI/xmpp-council-agenda

  78. Ge0rG has joined

  79. SamWhited

    Jingle Encrypted Transports was apparently already published, but it's in that column

  80. SamWhited

    as was the color one.

  81. daniel

    Maybe Because the two weeks ran out?

  82. SamWhited

    Could be, I'm not actually sure which is wrong.

  83. daniel

    I don't think I voted on either. But I'm fine with it

  84. Tobias


  85. Tobias

    4) Vote on advancing XEP-0387: XMPP Compliance Suites 2017

  86. Tobias

    to Draft that is

  87. Tobias

    I'm +1

  88. daniel


  89. SamWhited

    As the author I'm +0

  90. Tobias

    alright. I suppose the rest will vote on list

  91. ralphm has left

  92. dwd has joined

  93. Tobias

    5) Consider deprecation of Message Archiving ( https://xmpp.org/extensions/xep-0136.html )

  94. Kev

    I don't think that's in LC, is it? I don't remember seeing an LC recently, at least.

  95. Kev


  96. dwd

    Mea culpa, meeting was overrunning and I didn't notice the time.

  97. SamWhited

    oops, yes, that was supposed to be for issuing a LC, not for advancing to draft

  98. daniel

    I figured as much

  99. Tobias


  100. dwd

    I was just coming to that conclusion. I'm fine for a last call.

  101. Tobias

    LC for advancing it to Draft

  102. Tobias

    SamWhited, why do you want to deprecate XEP-136?

  103. SamWhited

    RE Message Archiving: we've discussed this before, but I'd like to complain about it again. I was having a conversation with someone the other day that was implementing a server and they said something about having trouble with message archiving. I mentioned that most people seem to use MAM now and that they should probably do that instead and got the usual "but archiving is the recommended one, why would I do MAM?"

  104. daniel

    I think we should advance mam

  105. daniel

    Before we deprecate something else

  106. dwd

    SamWhited, I agree with the sentiment, but let's LC MAM first.

  107. daniel

    I'm entirely with you on the confusion problem

  108. SamWhited

    I think we either need to advance MAM and deprecate archiving, or if that's not ready we need to go ahead and deprecate archiving to prevent confusion and just only have an experimental history XEP.

  109. Tobias

    yeah...I'd prefer advancing MAM first too

  110. SamWhited

    Since I've heard that "more work on MAM is coming soon" for at least a year, I'm not sure that it's ready to advance, but I would be all for issuing a LC and finding out.

  111. daniel

    I don't think we should deprecate before there is something else

  112. Kev

    I don't like deprecating in favour of something with lower advancement, but in this case I think the case is fairly compelling.

  113. SamWhited

    I disagree, I think we should absolutely deprecate if the community has standardized on something else. Even if that thing is experimental, it can still be the recommendation of this council.

  114. dwd

    SamWhited, Again, I agree with the sentiment, but I'd want to try pretty hard to nail '313 before deprecating without a replacement.

  115. Kev

    It's not like there's nothing else, just that the something else isn't Draft.

  116. Kev

    Whether we continue tweaking MAM or not, we know it's already vastly better than 136.

  117. SamWhited

    But I do agree that issuign a LC for MAM seems like a reasonable step, maybe I'm wrong about it needing more work.

  118. Ge0rG

    does the Council want to encourage 136 implementations until MAM is finished?

  119. Kev

    Ge0rG: Hopefully not :)

  120. daniel

    Though I admit that the mam situation is a bit problematic. (lots of people use it but it's not really being worked on)

  121. SamWhited

    I hope not too

  122. daniel

    But we should fix that situation

  123. Tobias


  124. Ge0rG

    Kev: in that case deprecating it now might be good?

  125. dwd

    Ge0rG, I take your point, but I would prefer a push on MAM *first*. If that doesn't work, let's revisit.

  126. SamWhited

    That is a compromise I can live with. In that case, I would like us to vote on a LC for MAM if possible.

  127. Kev

    I can probably arrange for a 313 author to request an LC if you want ...

  128. SamWhited

    This is the second or third time I've run into this specific XEP as a source of confusion, so I'm rather eager to find a solution

  129. SamWhited

    Or we can just issue one, no?

  130. Kev

    SamWhited: It was a flippancy, Matt and I are the authors.

  131. dwd

    Kev, Are you so doing? I think you need to ask an Editor, if you can find one...

  132. daniel has left

  133. daniel has joined

  134. daniel

    SamWhited: does that work without the author requesting it?

  135. daniel

    Or is that a good idea without the author requesting it

  136. SamWhited

    daniel: It seems like a good way to encourage authors to submit the changes they've said they have almost ready for a year or more :)

  137. Kev

    I don't think Council needs the author to request it, although doing so when the author thinks it isn't ready might be a poor idea.

  138. Kev

    Anyway, issue the LC. No harm will come, as long as you don't then advance it prematurely :)

  139. daniel

    Let issue a LC. Maybe that encourages some discussion. Or the author to submit more changes and thus cancel lc

  140. Kev

    (Or issue the vote for an LC, as clearly I wouldn't tell Council how to vote)

  141. Ge0rG

    Kev: if 136 is not an alternative to 313, deprecating 136 is independent of pushing forward 313, right?

  142. Tobias

    sure...fine with issuing a LC

  143. SamWhited

    Thanks all. +1 to LC from me (obviously)

  144. Kev

    Ge0rG: I'm not Council, and Council don't want to deprecate 136 until 313 is LCd, so ... path of least resistance.

  145. daniel

    +1 for the LC

  146. dwd

    I would be happy to vote on an LC for 313 now. (And will vote for, FWIW).

  147. dwd

    Oh. So yeah, -1.

  148. dwd


  149. dwd

    +1. I meant +1.

  150. Tobias

    ok..to make it clear in the history let's start fresh

  151. Tobias

    6) Vote on issuing a LC on MAM

  152. Tobias


  153. dwd


  154. SamWhited


  155. daniel


  156. Tobias


  157. SamWhited

    I'll add a card; thanks all.

  158. Tobias

    7) Deprecate XHTML-IM

  159. daniel


  160. daniel

    Link Mauve loves that xep

  161. dwd

    Where did that one spring from?

  162. Tobias


  163. Tobias

    he wants us to discuss this yearly

  164. Tobias


  165. dwd

    Oh. Has it been discussed on the list yearly, too?

  166. daniel

    I think that needs list discussion

  167. Tobias


  168. daniel

    Even though I personally hate that xep and would like to deprecate it I think it does have a lot of fans

  169. dwd

    Yeah. Last time it was discussed on the list was back in December.

  170. SamWhited

    Okay, back to this

  171. Ge0rG

    I love XHTML-IM.

  172. daniel

    Or we should maybe do some 'markup in im' xep

  173. SamWhited

    Similar to the MAM thing, I was playing around with another web client a few days ago and found, yet again, an implementation of XHTML-IM that simply dumped HTML into the DOM and made it trivial to implement XSS's

  174. dwd

    daniel, Down. Mark*down*.

  175. daniel

    Since markup seems to be what cool IMs do theses days

  176. SamWhited

    I have never found an XHTML-IM implementation that didn't have this issue (or rather, some didn't, but they did have it originally and it had been fixed)

  177. daniel

    *that *

  178. SamWhited

    Literally "never", that is not me making a grand statement for the purpose of making a point.

  179. Zash

    Big warning in <blink> and red letters at the top of the document?

  180. SamWhited

    I'm sure *someone* has done this right the first time, but it seems that the default is that the spec encourages people to do it wrong. By leaving it as a recommendation I think we are encouraging security issues.

  181. daniel

    SamWhited: yes I'm personally all in favor for the same arguments. I think we should even do the 'what ever is worse than deprecated'

  182. Ge0rG

    SamWhited: all modern applications are full of security issues.

  183. daniel

    But it does need list discussion

  184. SamWhited

    Even if we're not comfortable deprecating Message Archiving until there is a replacement, I think this is a security problem and therefore should absolutely be obsoleted (not just deprecated) as soon as possible.

  185. daniel

    Especially if you want to get Link Mauve on board

  186. Tobias

    yeah, SamWhited, do you mind writing a mail to standard about the plan of deprecating it and we'll see what comes out of that?

  187. daniel

    He *loves* xhtml

  188. SamWhited

    Sounds good, I'll write something up for the list.

  189. Tobias


  190. SamWhited

    Thanks for humoring me.

  191. Tobias

    7) Date of next

  192. Tobias

    same time next week

  193. daniel


  194. Tobias


  195. SamWhited


  196. Tobias

    8) AOB

  197. daniel

    None from me

  198. dwd

    Just a heads-up that I'll be writing up Surevine's TOTP approach into a XEP or two shortly.

  199. Tobias


  200. SamWhited


  201. SamWhited

    Tobias: time based multi-factor auth (Google Authenticator, Yubico Auth, etc.)

  202. Tobias


  203. Tobias


  204. Tobias

    no other AOB

  205. Tobias bangs the gavel

  206. Tobias

    thanks everybody

  207. SamWhited

    I can't wait to see that; I'd love to be able to use my yubikey as a second factor in Conversations one of these days

  208. Ge0rG

    I'd be happy with per-device passwords already.

  209. jonasw

    I can’t believe people would simply dump an XHTML-IM tree in anything capable of doing something bad with that.

  210. dwd

    Ge0rG, That has to be included.

  211. jonasw

    that makes me sad.

  212. dwd

    Ge0rG, Otherwise you end up having to hit the TOTP device every time you switch networks.

  213. Ge0rG

    jonasw: people go for convenience first.

  214. jonasw

    Ge0rG, insert rage here

  215. Ge0rG

    dwd: right. There needs to be some sensible trade-off here.

  216. daniel has left

  217. daniel has joined

  218. Flow has left

  219. Flow has joined

  220. daniel has left

  221. moparisthebest

    yubikey might have some value there

  222. moparisthebest

    but otherwise, all apps are on the phone

  223. moparisthebest

    so to login to conversations you need your phone anyway, and you are back to 1 factor no?

  224. Ge0rG

    moparisthebest: the trick is to have a _second_ phone for 2FA!

  225. jere has joined

  226. moparisthebest

    ah so user friendly Ge0rG :P

  227. dwd

    moparisthebest, You're right, but the 2FA control is on the account, so this is a generally recurring problem.

  228. Ge0rG

    we really need some notion of device identity.

  229. dwd

    moparisthebest, I can recommend a watch for this, BTW. :-)

  230. moparisthebest

    Ge0rG, you can already see your other online devices right?

  231. Ge0rG

    moparisthebest: yes and no. Let me write a short mail to standards@.

  232. moparisthebest

    I'm still undecided on the whole thing, I think it's fine for people that want it, I don't think I'd want it

  233. moparisthebest

    I'm not positive it's that much better than just long random passwords for most threats

  234. moparisthebest

    so you've got:

  235. dwd

    moparisthebest, No, it is.

  236. moparisthebest

    1. password leaks, yahoo hacks, etc - long random unique per account password and 2fa protect you the same

  237. moparisthebest

    2. NSA is after you - cracking long random password is harder than hacking your phone and stealing your 2fa stuff

  238. moparisthebest

    3. Kidnapped - same

  239. moparisthebest

    what am I missing? I guess if some random hacks your computer and not your phone? in which case 2fa is an advantage

  240. SamWhited

    The point is that they work together; 1. doesn't actually make sense, it's operating under the assumption that they are two orthogonal things that attempt to solve the same problems. You have to use both together, 2fa is not a replacement for long random unique-per-account passwords.

  241. SamWhited

    Same with two. The point is that they have to crack a long random password *and* steal your 2fa stuff. Doesn't matter which one is harder for any given actor.

  242. moparisthebest

    but for #1 it doesn't make it any harder with 2fa

  243. dwd

    moparisthebest, Yes, it does.

  244. moparisthebest

    #2 the NSA can just do both, *maybe* it makes it a bit harder, fair

  245. moparisthebest

    and I mean who are we kidding, the NSA just hacks your server, it doesn't need your credentials, so that was a dumb example on my part :)

  246. SamWhited

    It does if your bank was storing your password in plain text. Or if it is random, long, and hard to break but your goal is to slow them down even further even if they do break it.

  247. dwd

    SamWhited, Or if you get phished.

  248. moparisthebest

    banks are one of the few places I think 2fa makes sense

  249. SamWhited

    dwd: indeed

  250. moparisthebest

    too bad none of them implement it :'(

  251. SamWhited

    It's also almost not worth using the NSA as an example. Most peoples threat model doesn't include a state level adversary.

  252. moparisthebest

    yep I agree

  253. SamWhited

    ah yah, I missed your last statement on that.

  254. dwd

    moparisthebest, There *is* a problem in that many TOTP implementations store the TOTP secret in the clear, and that's bad. It's difficult (especially in XMPP) to do otherwise, though our implementation at least stores it encrypted in the database.

  255. moparisthebest

    if you do, you should just stay off the internet really :)

  256. moparisthebest

    I guess in my mind TOTP makes more sense for things you log into, do your business, and log out of

  257. moparisthebest

    and less for something you plan on staying logged into forever

  258. moparisthebest

    especially from your phone that doubles as your totp generator

  259. dwd

    moparisthebest, Sure, which is why any time you'd save your password in the client, you need a way to avoid the TOTP.

  260. moparisthebest

    that sounds like a good system then dwd :)

  261. dwd

    moparisthebest, And amazing, we have already implemented most of it. Got to replace the crappy per-client password type thing with a better one I've designed, but it's certainly proved the concept.

  262. dwd

    moparisthebest, The really painful thing isn't merely using TOTP on the phone, BTW. The really painful thing is signing up to TOTP on the phone.

  263. moparisthebest

    yea actually that would be a giant pain

  264. moparisthebest

    back to Ge0rG 's 2 phone thing :)

  265. dwd

    moparisthebest, But yay, because I don't have a solution there at all.

  266. moparisthebest

    what about 2 mirrors?

  267. moparisthebest

    oh, front-facing camera and 1 mirror

  268. moparisthebest

    problem solved!

  269. dwd

    moparisthebest, I suspect that trying to open a totp URI on Android might well actually do the right thing.

  270. moparisthebest

    that's the way, if any totp apps support that

  271. moparisthebest

    I find redhat's the best https://freeotp.github.io/

  272. Zash has left

  273. ralphm has joined

  274. Lance has joined

  275. Lance has left

  276. Zash has left

  277. jere has left

  278. ralphm has left

  279. ralphm has left

  280. Flow has left

  281. Flow has joined

  282. ralphm has left

  283. Zash has joined

  284. Tobias has joined

  285. ralphm has left

  286. Flow has joined

  287. Flow has joined

  288. Flow has left

  289. Tobias

    Minutes are out.

  290. Tobias has left

  291. jere has joined

  292. Flow has joined

  293. Flow has left

  294. Ge0rG

    moparisthebest: https://mail.jabber.org/pipermail/standards/2017-October/033544.html btw

  295. Zash has left

  296. jere has joined

  297. jere has joined

  298. SamWhited has left

  299. Tobias has joined

  300. moparisthebest has joined

  301. Zash has left

  302. peter has joined

  303. Tobias has left

  304. Zash has joined

  305. Zash has left

  306. Zash has left

  307. Zash has left

  308. Zash has left

  309. Zash has left

  310. Zash has left

  311. Zash has left

  312. Zash has left

  313. Zash has left

  314. Zash has left

  315. Zash has left

  316. Zash has left

  317. Zash has left

  318. Zash has left

  319. Zash has left

  320. Zash has left

  321. Zash has left

  322. Zash has left

  323. Zash has left

  324. Zash has left

  325. Zash has left

  326. Zash has left

  327. Zash has left

  328. Zash has left

  329. Zash has left

  330. Zash has left

  331. Zash has left

  332. Zash has left

  333. Zash has left

  334. Zash has left

  335. Zash has left

  336. Zash has left

  337. Zash has left

  338. Zash has left

  339. Zash has left

  340. Zash has left

  341. Zash has left

  342. Zash has left

  343. Zash has left

  344. Zash has left

  345. Zash has joined

  346. Zash has left

  347. Zash has joined

  348. SamWhited has left

  349. pep.

    Wow deprecate xhtml-im. Didn't see that coming.

  350. SamWhited

    I try to keep you on your toes :)

  351. pep.

    People are dumb, sure, help them fix their client. Otherwise you can do whatever other markup you want with it. You want markdown, her xhtml-im! You want rST, use xhtml-im

  352. pep.

    use* dumb android

  353. Tobias has left

  354. vanitasvitae has left

  355. Tobias has left

  356. daniel has joined

  357. vanitasvitae has left

  358. daniel has left

  359. peter has left

  360. Tobias has joined

  361. Tobias has joined

  362. Zash has left

  363. Zash has left

  364. Zash has joined