XSF Discussion - 2017-02-20

  1. intosi has joined
  2. mancho has left
  3. vurpo has left
  4. intosi has left
  5. Kev has left
  6. intosi has joined
  7. narcode has left
  8. narcode has joined
  9. intosi has left
  10. Tobias has joined
  11. Tobias has joined
  12. Kev has left
  13. intosi has joined
  14. Zash has left
  15. intosi has left
  16. nyco has left
  17. nyco has joined
  18. Kev has left
  19. daniel has left
  20. kalkin has left
  21. kalkin has joined
  22. daniel has joined
  23. uc has joined
  24. intosi has joined
  25. intosi has left
  26. vurpo has left
  27. vurpo has joined
  28. Kev has left
  29. intosi has joined
  30. Steve Kille has joined
  31. jere has left
  32. intosi has left
  33. mancho has joined
  34. Steve Kille has left
  35. SamWhited has left
  36. Kev has left
  37. intosi has joined
  38. intosi has left
  39. Yagiza has joined
  40. xnyhps has left
  41. intosi has joined
  42. Guus has left
  43. Yagiza has left
  44. Kev has left
  45. intosi has left
  46. SamWhited has left
  47. jonasw good morning
  48. kalkin has left
  49. sezuan has left
  50. Alex has joined
  51. kalkin has joined
  52. xnyhps has left
  53. Piotr Nosek has joined
  54. goffi has joined
  55. Alex has left
  56. intosi has joined
  57. jonasw has left
  58. xyz has joined
  59. dwd has joined
  60. dwd has left
  61. dwd has joined
  62. intosi has left
  63. Yagiza has joined
  64. Kev has left
  65. jubalh has joined
  66. jubalh has left
  67. xyz has left
  68. Lance has joined
  69. blipp has left
  70. suzyo has joined
  71. xyz has joined
  72. xnyhps has left
  73. blipp has joined
  74. xyz has left
  75. tim@boese-ban.de has joined
  76. tim@boese-ban.de has joined
  77. Lance has left
  78. jubalh has joined
  79. Kev has left
  80. intosi has joined
  81. kalkin has left
  82. jcbrand has joined
  83. jubalh has left
  84. jubalh has joined
  85. intosi has left
  86. kalkin has joined
  87. suzyo has left
  88. suzyo has joined
  89. Valerian has joined
  90. waqas has left
  91. Kev has left
  92. Kev has left
  93. ralphm has left
  94. Kev has left
  95. moparisthebest has left
  96. moparisthebest has joined
  97. mhterres has joined
  98. Martin has joined
  99. Kev has left
  100. intosi has joined
  101. mancho has left
  102. mancho has joined
  103. dwd has joined
  104. daniel has left
  105. daniel has joined
  106. Kev has left
  107. kalkin has left
  108. jubalh has left
  109. mancho has left
  110. jubalh has joined
  111. jubalh has left
  112. kalkin has joined
  113. Sonny has left
  114. mancho has joined
  115. Yagiza has left
  116. Yagiza has joined
  117. xnyhps has left
  118. blipp has left
  119. blipp has joined
  120. Kev has left
  121. Sonny has left
  122. jcbrand has left
  123. dwd has joined
  124. Guus has left
  125. mancho has left
  126. Sonny has left
  127. jcbrand has joined
  128. Zash has joined
  129. Guus has left
  130. blipp has left
  131. blipp has joined
  132. jonasw has left
  133. mhterres has left
  134. mhterres has joined
  135. mhterres has left
  136. mhterres has joined
  137. mimi89999 has joined
  138. Valerian has left
  139. Tobias has joined
  140. Tobias has joined
  141. Tobias has joined
  142. mimi89999 has joined
  143. Flow has joined
  144. mimi89999 has joined
  145. Flow has left
  146. Kev has left
  147. Tobias has joined
  148. tim@boese-ban.de has left
  149. jcbrand has left
  150. xyz has joined
  151. jonasw has left
  152. jere has joined
  153. daniel has left
  154. jere has left
  155. jere has joined
  156. xyz has left
  157. xyz has joined
  158. daniel has joined
  159. Valerian has joined
  160. mancho has joined
  161. jcbrand has joined
  162. mancho has left
  163. mimi89999 has left
  164. mimi89999 has joined
  165. mancho has joined
  166. Sonny has left
  167. Piotr Nosek has left
  168. Flow has joined
  169. Tobias has joined
  170. Holger There seems to be a consensus that predictable resource strings introduce a privacy issue. Do we have any text in any XEP (or on the wiki or the mailing list) explaining the issue?
  171. MattJ https://xmpp.org/rfcs/rfc6120.html#bind-generation
  172. Kev has left
  173. Holger MattJ: Thanks. This says you "might be able to determine if the client [...] is online" if you know the resource string. There's no explanation how you would determine that, right?
  174. MattJ Not anything explicit that I know of
  175. Holger MattJ: I'm aware of a few ways to do that at least with ejabberd users, but each of those are spec or implementation issues which IMO should be fixed either way (rather than only hidden by making the resource string unpredictable).
  176. Ge0rG Holger: +1
  177. MattJ But this is implicitly assumed by various XEPs
  178. Kev has left
  179. Ge0rG Holger: the only issue I'm aware of is periodic sending of IQs to a full JID, to probe the client availability and network latency
  180. Holger MattJ: Unpredictable resource strings are assumed?
  181. xyz has left
  182. Ge0rG It's also a really poor idea to use UUIDs for randomness if we have the full power of unicode (or at least base32 / base64)
  183. Holger Indeed.
  184. MattJ I'd wager that yes, numerous XEPs rely on unpredictable resource strings for security/privacy purposes
  185. Ge0rG YouTube, the world's most used video platform, manage to identify videos by less than a dozen characters. Why do we need to use 36 characters to identify two clients on an account?
  186. Kev If there's a standard for how to do something equivalent to UUID (global uniqueness without fingerprinting) in fewer bytes, using that instead of UUID seems entirely sensible.
  187. Ge0rG Are we protecting from enumeration attacks? From birthday attacks? What is the actual amount of randomness required in a resource to prevent those?
  188. Holger Kev: Why do we need a standard for that? I mean there's no interop requirement?
  189. jonasw w
  190. jonasw ^
  191. Kev Holger: Well, we'd at least want it to be consistently implemented across clients, else you can fingerprint (which probably isn't the end of the world, but seems like something we'd want to prevent).
  192. Ge0rG Kev: sticking to default implementations is what causes user-visible URLs like https://xmpp.yaxim.org:5281/upload/54f59abf-de9b-4fb9-a1e4-f0b5b78a0a9d/a5f532df-0fef-47c4-81a9-2aff690419fc.jpg
  193. intosi Holger: libraries have the benefit of people not writing their own random identifier generator.
  194. intosi * standard methods present in libraries, I mean.
  195. jonasw getentropy(nbits=32) | base64 | strip('=') should be possible with every standard library.
  196. jonasw we are requiring PRECIS which has *much less* support than that
  197. intosi Which base64?
  198. intosi But yeah, another well-defined method could work equally well.
  199. xyz has joined
  200. jonasw intosi: okay, point taken. getentropy(nbits=32) | base64 | tr('_/', '_-') | strip('=')
  201. intosi When unicode comes into play, I'm less inclined to believe that every client gets it right, though. Unicode is hard.
  202. jonasw base64 is luckily only ascii
  203. Ge0rG what we are looking for is a number of random bits packed into as few characters as possible for a given element
  204. Kev Well, not quite.
  205. jonasw base-emoji
  206. Zash Base 85
  207. Kev We're also looking for it to be typable by server admins grepping for logs, etc.
  208. Kev And visibly distinguishable.
  209. Kev Simply picking random bits forced into UTF-8 clearly wouldn't work, for example.
  210. Ge0rG Kev: uuids are not very visibly distinguishable.
  211. Kev If you give me two UUIDs, I'm fairly sure I can tell you if they're the same.
  212. jonasw Kev: agreed (with random bits in utf-8), not only because of distinguiushability, but because it also needs to pass resourceprep and/or precis unmodified. that’s nontrivial.
  213. Ge0rG Kev: what if you have a complex scenario with N clients in a MUC, a set of M reflected messages with rewritten UUID ids? For which values of N and M can you keep N+2*M UUIDs in your short-term memory?
  214. Zash Disco identity ?
  215. jonasw what about dictionary-based strings?
  216. jonasw just sample from /usr/share/dict/british-english-insane (it’s a thing!)
  217. Holger Zash: There's no disco identity when staring at XEP examples ...
  218. Ge0rG base64-strings have better visible distinguishability due to more uppercase/lowercase.
  219. Kev Ge0rG: In what scenario are you imagining someone debugging such a thing and using the resources as the mental identifiers?
  220. Kev As I said earlier, if we can more tightly pack than UUID, while still maintaining human readability, great.
  221. Kev (And the other desirable properties of UUIDs)
  222. intosi Basically still gibberish. I'm not convinced it would make a difference, I would suck at remembering many of either UUID, base64, or picks-from-a-wordlist-with-sufficient-entropy.
  223. intosi For all of them, I would just use the first four or five chars anyway.
  224. Ge0rG Kev: which identifiers would you use if all you have at hand are debug logs?
  225. Holger Kev: I'm still quite baffled you'd list 'readability' as one of the properties of UUIDs :-)
  226. Kev Nicks in a MUC, in the usual case of them being pretty static.
  227. Holger (Then again these XMPP people are used to reading XML ...)
  228. Kev Holger: They're not *nice*, but it is possible to straightforwardly read them.
  229. Holger Kev: But what makes them any more readable than e.g. Base64?
  230. Ge0rG Kev: but I want it *nice*.
  231. Kev Compared with random UTF-8, which is impossible to read because you've no idea which of the many matching characters you're looking at.
  232. Kev Holger: Nothing.
  233. Holger Oh. Well yeah there's always something worse.
  234. jonasw Kev: nobody was seriously talking about using random utf-8
  235. jonasw (I hope.)
  236. Kev jonasw: You might not be taking Ge0rG seriously, but I was still trying to address his point that we should be using UTF.
  237. jonasw Kev: I’m pretty sure Ge0rG was only making a point that using only hex is a waste of bytes and we should use base64 or something.
  238. Ge0rG https://gist.github.com/windytan/7910910/
  239. Kev jonasw: Given he explicitly said we should use the power of UTF-8, I don't think so :)
  240. jonasw "the power of unicode", right…
  241. Kev You're right, he said unicode, not UTF-8.
  242. Ge0rG Kev: actually, I should have written "a number of random bits packed into as few bytes as possible" - that should rule out non-ascii
  243. Kev Why?
  244. Kev You get denser packing with UTF-8 than with ASCII encoded as UTF-8.
  245. intosi Well, that emoji-encoder uses four bytes per byte ;)
  246. jonasw Kev: I’m not sure about that. with ascii, you have a constant 7 bits / byte, with UTF-8 you lose bits for codepoints above 127 for signalling
  247. Ge0rG intuitively, I'm with jonasw here.
  248. Kev I might be wrong, conceivably. It doesn't match my mental mapping of UTF-8, but I know that's a poor mapping.
  249. jonasw in any case, that’s not the point of the discussion.
  250. Kev I think you get to use the extra bit as encoding for at least the first byte.
  251. Kev Sure.
  252. Ge0rG nobody has still said what attack we are trying to prevent, and how many bits of randomness are required to guard it off
  253. jonasw (using any fancy unicode would be very hard, as I said, with the mappings done by resourceprep et al anyways)
  254. Kev The important thing isn't that these are UUIDs, it's that they have the properties of UUIDs and are consistently implemented.
  255. Sonny has left
  256. Ge0rG in a world where clients leak their presence like crazy, having 256 bits of randomness in the resource might be a solution to the wrong problem.
  257. Kev goes back to work.
  258. kalkin has left
  259. Sonny has left
  260. kalkin has joined
  261. Guus has left
  262. winfried has left
  263. xyz has left
  264. Vinilox has left
  265. Zash has joined
  266. Zash has left
  267. Zash has joined
  268. Sonny has left
  269. mancho has left
  270. waqas has joined
  271. moparisthebest has left
  272. SouL has joined
  273. SouL has joined
  274. Piotr Nosek has joined
  275. SouL has joined
  276. SouL has joined
  277. SouL has joined
  278. SouL has joined
  279. suzyo has left
  280. suzyo has joined
  281. Steve Kille has joined
  282. jubalh has joined
  283. jubalh has left
  284. Valerian has left
  285. Valerian has joined
  286. xyz has joined
  287. jcbrand has left
  288. jcbrand has left
  289. Kev has left
  290. Kev has left
  291. jonasw has left
  292. Flow has joined
  293. Flow has joined
  294. jere has joined
  295. xyz has left
  296. Neustradamus has left
  297. daurnimator has left
  298. SouL has joined
  299. mancho has joined
  300. daurnimator has left
  301. kalkin has left
  302. kalkin has joined
  303. Valerian has left
  304. Valerian has joined
  305. mimi89999 has left
  306. vurpo has left
  307. vurpo has joined
  308. suzyo has left
  309. suzyo has joined
  310. Steve Kille has left
  311. mimi89999 has left
  312. Zash XEP-0198 doesn't define what should happen when a session times out, or am I missing something?
  313. Kev has left
  314. vurpo has left
  315. vurpo has joined
  316. mancho has left
  317. xyz has joined
  318. mancho has joined
  319. Steve Kille has left
  320. xyz has left
  321. Kev has left
  322. SamWhited has left
  323. Piotr Nosek has left
  324. Piotr Nosek has joined
  325. vurpo has left
  326. vurpo has joined
  327. vurpo has left
  328. vurpo has joined
  329. xyz has joined
  330. sezuan has left
  331. Valerian has left
  332. ralphm has left
  333. xnyhps has left
  334. jere has joined
  335. mimi89999 has left
  336. kalkin has left
  337. Zash Ge0rG: Btw, for maximum entropy per byte with base64, get a multiple of 3 bytes. You get a multiple of 4 bytes out and no padding.
  338. kalkin has joined
  339. Ge0rG Zash: or you just strip away the padding
  340. Zash Ge0rG: There may still encoded 0 bits
  341. Zash Ge0rG: There may still be encoded 0 bits
  342. Ge0rG Zash: but how does that relate to my original statement?
  343. Zash Ge0rG: Being pedantic.
  344. Zash 1 byte input → XX== 2 byte input → XXX= 3 byte input → XXXX
  345. Ge0rG Zash: I never proposed base64 as _the_ solution
  346. xyz has left
  347. xyz has joined
  348. daniel has left
  349. daurnimator has left
  350. xyz has left
  351. xyz has joined
  352. vurpo has left
  353. vurpo has joined
  354. jubalh has joined
  355. xyz has left
  356. jonasw (I do)
  357. Kev has left
  358. xyz has joined
  359. intosi has left
  360. intosi has joined
  361. tim@boese-ban.de has left
  362. vurpo has left
  363. Lance has joined
  364. Alex has joined
  365. xyz has left
  366. intosi has left
  367. intosi has joined
  368. Flow has joined
  369. xnyhps has left
  370. Steve Kille has left
  371. stpeter has joined
  372. jubalh has left
  373. mhterres has left
  374. mancho has left
  375. suzyo has left
  376. Sonny has left
  377. daurnimator has left
  378. suzyo has joined
  379. Yagiza has left
  380. jcbrand has left
  381. ralphm has left
  382. Piotr Nosek has left
  383. Martin has left
  384. Martin has joined
  385. Martin has left
  386. Martin has joined
  387. Martin has left
  388. suzyo has left
  389. suzyo has joined
  390. uc has left
  391. uc has joined
  392. intosi has left
  393. intosi has joined
  394. Kev has left
  395. Kev has left
  396. bjc has joined
  397. vurpo has left
  398. vurpo has joined
  399. xyz has joined
  400. bjc has left
  401. Kev has left
  402. mimi89999 has left
  403. vurpo has left
  404. vurpo has joined
  405. Neustradamus has joined
  406. Zash has joined
  407. mancho has left
  408. nyco has left
  409. nyco has joined
  410. xyz has left
  411. xyz has joined
  412. intosi has left
  413. daniel has left
  414. daniel has joined
  415. intosi has joined
  416. xyz has left
  417. nyco has joined
  418. xyz has joined
  419. nyco has joined
  420. Zash has joined
  421. Zash Can someone enlighten me about what the sane thing to do about this would be: https://prosody.im/issues/issue/836
  422. daniel has left
  423. xyz has left
  424. xyz has joined
  425. daniel has joined
  426. Zash Specifically, what to do with un-acked stanzas when the session times out and what order things should happen in.
  427. Ge0rG Zash: the messages get error-reflected to the MUC, causing a kick. I think this is valid
  428. Ge0rG At least I don't see anything mandate that the user should leave normally
  429. Zash Ge0rG: I don't see any text saying anything in either direction
  430. xyz has left
  431. xyz has joined
  432. suzyo has left
  433. Guus has left
  434. suzyo has joined
  435. winfried has left
  436. suzyo has left
  437. Ge0rG Zash: ask the submitter?
  438. suzyo has joined
  439. Kev has left
  440. Vinilox has left
  441. Lance has left
  442. xyz has left
  443. suzyo has left
  444. suzyo has joined
  445. Lance has joined
  446. suzyo has left
  447. Alex has left
  448. jubalh has joined
  449. suzyo has joined
  450. daurnimator has left
  451. goffi has left
  452. xyz has joined
  453. Kev has left
  454. Lance has left
  455. Lance has joined
  456. suzyo has left
  457. Lance has left
  458. Lance has joined
  459. Alex has joined
  460. intosi has left
  461. intosi has joined
  462. xyz has left
  463. Guus has left
  464. Guus has left
  465. efrit has joined
  466. intosi has left
  467. intosi has joined
  468. Sonny has left
  469. Tobias has joined
  470. Guus has left
  471. Steve Kille has joined
  472. Kev has left
  473. Guus has left
  474. Zash has left
  475. moparisthebest has joined
  476. moparisthebest has left
  477. moparisthebest has joined
  478. Guus has left
  479. sezuan has left
  480. jonasw has left
  481. jonasw has left
  482. Kev has left
  483. daurnimator has left
  484. Lance has left
  485. Lance has joined
  486. Lance has left
  487. Lance has joined
  488. Lance has left
  489. Zash has joined
  490. Lance has joined
  491. Kev has left
  492. Lance has left
  493. Lance has joined
  494. Lance has left
  495. Lance has joined
  496. jubalh has left
  497. Kev has left