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