XSF Discussion - 2015-10-15


  1. Zash has left

  2. dwd has left

  3. dwd has left

  4. Zash has joined

  5. dwd has left

  6. dwd has left

  7. dwd has left

  8. dwd has left

  9. Zash has joined

  10. stpeter has joined

  11. dwd has left

  12. stpeter has left

  13. dwd has left

  14. dwd has left

  15. dwd has left

  16. dwd has left

  17. dwd has left

  18. dwd has left

  19. dwd has left

  20. dwd has left

  21. dwd has left

  22. dwd has left

  23. dwd has left

  24. arc has joined

  25. dwd has left

  26. dwd has left

  27. dwd has left

  28. SamWhited has left

  29. SamWhited has left

  30. arc has left

  31. SamWhited has left

  32. SamWhited has left

  33. dwd has left

  34. dwd has left

  35. SamWhited has left

  36. dwd has left

  37. dwd has left

  38. SamWhited has left

  39. dwd has left

  40. dwd has left

  41. dwd has left

  42. dwd has left

  43. dwd has left

  44. dwd has left

  45. tim@boese-ban.de has joined

  46. dwd has left

  47. dwd has left

  48. dwd has left

  49. dwd has left

  50. kourosh has joined

  51. dwd has left

  52. dwd has left

  53. kourosh has left

  54. dwd has left

  55. Valérian has joined

  56. dwd has left

  57. dwd has left

  58. dwd has left

  59. dwd has left

  60. dwd has left

  61. dwd has left

  62. dwd has left

  63. Valérian has left

  64. ralphm has left

  65. dwd has left

  66. dwd has left

  67. dwd has left

  68. Valérian has joined

  69. dwd has left

  70. dwd has left

  71. intosi has joined

  72. dwd has left

  73. Valérian has left

  74. Flow has joined

  75. ralphm has left

  76. Flow has left

  77. daurnimator has joined

  78. dwd has left

  79. dwd has left

  80. dwd has left

  81. dwd has left

  82. Will has joined

  83. Tobias has joined

  84. Zash has joined

  85. ralphm has left

  86. Alex has joined

  87. xnyhps has left

  88. daurnimator has left

  89. daurnimator has joined

  90. daurnimator has left

  91. daurnimator has joined

  92. daurnimator has left

  93. ralphm has left

  94. intosi has left

  95. intosi has joined

  96. ralphm has left

  97. dwd has left

  98. ralphm has left

  99. ralphm has left

  100. intosi has left

  101. intosi has joined

  102. intosi has left

  103. intosi has joined

  104. ralphm has left

  105. ralphm has left

  106. Tobias has joined

  107. daniel has left

  108. daniel has joined

  109. daniel has joined

  110. daniel has joined

  111. ralphm has left

  112. ralphm has left

  113. Valérian has joined

  114. xnyhps has left

  115. daniel has left

  116. daniel has joined

  117. ralphm has left

  118. Tobias has joined

  119. xnyhps has left

  120. ralphm has left

  121. arune has left

  122. ralphm has left

  123. ralphm has left

  124. ralphm has left

  125. ralphm has left

  126. dwd has left

  127. ralphm has left

  128. daniel has joined

  129. daniel has joined

  130. daniel has left

  131. daniel has joined

  132. Flow has joined

  133. daniel has left

  134. daniel has joined

  135. Zash has joined

  136. daniel has joined

  137. daniel has joined

  138. dwd has left

  139. daniel has left

  140. daniel has joined

  141. daniel has left

  142. daniel has joined

  143. daniel has left

  144. daniel has joined

  145. daniel has left

  146. daniel has joined

  147. daniel has left

  148. daniel has joined

  149. Tobias has joined

  150. waqas has joined

  151. daniel has left

  152. daniel has joined

  153. daniel has left

  154. daniel has joined

  155. Martin has joined

  156. Will has left

  157. Zash has joined

  158. Flow has joined

  159. daniel has left

  160. daniel has joined

  161. Martin has left

  162. daniel has left

  163. daniel has joined

  164. daniel has left

  165. daniel has joined

  166. daniel has left

  167. daniel has joined

  168. ralphm has left

  169. daniel has left

  170. waqas has left

  171. daniel has left

  172. daniel has left

  173. dwd has left

  174. waqas has joined

  175. daniel has joined

  176. Zash has joined

  177. Tobias has joined

  178. Will has left

  179. daniel has left

  180. dwd has left

  181. xnyhps has left

  182. daniel has left

  183. ralphm has left

  184. daniel has left

  185. stpeter has joined

  186. daniel has joined

  187. ralphm has left

  188. Zash has joined

  189. Flow has joined

  190. dwd has left

  191. tim@boese-ban.de has joined

  192. SamWhited has left

  193. tim@boese-ban.de has left

  194. daniel has left

  195. daniel has joined

  196. Martin has joined

  197. daniel has left

  198. Tobias

    any XEP editor around?

  199. SamWhited

    Tobias: What's up? They just had a meeting, and I think a few people ran off to other meetings, but I'm sure someone is around. Don't ask-to-ask, just ask :)

  200. Tobias

    http://mail.jabber.org/pipermail/standards/2015-August/030246.html shouldn't the protoxep under 2) have a XEP number by now? the remaining votes are still outstanding i think and are irrelevant by now

  201. Flow has left

  202. ralphm has left

  203. ralphm has left

  204. dwd has left

  205. Martin has left

  206. SamWhited has left

  207. Will has left

  208. dwd has left

  209. Zash has joined

  210. dwd has left

  211. SamWhited has left

  212. Kevish has left

  213. intosi has left

  214. intosi has joined

  215. daniel has left

  216. ralphm has left

  217. ralphm has left

  218. ralphm has left

  219. stpeter

    Tobias: seems like it, yes

  220. daniel has left

  221. dwd has left

  222. dwd has left

  223. dwd has left

  224. dwd has left

  225. Flow has joined

  226. tim@boese-ban.de has left

  227. Flow

    SamWhited: reading editor@ backlog. Just want to clarify that you don't need to flush on stanza/nonza boundaries to close the side channel. You only need to flush (i.e. drop the deflate dictionary) when you flush the (TCP) socket. Which yields better compression then flushing on every stanza/nonza.

  228. dwd has left

  229. Zash silently curses whoever made him notice 'then' vs 'than'

  230. Flow

    Zash: uh, thanks for pointing this out :)

  231. SamWhited

    Flow: I think we're doing it on stanza boundaries (for reasons which I don't remember), but that makes sense.

  232. Flow

    SamWhited: If you remember the reasons then let me know. Unrelated to compression: Smack used to flush the socket after every stanza, which caused "heavy" OS overhead. I've changed it to only flush if the send queue is empty, which increased Smack's throughput by some numbers.

  233. Zash

    Wouldn't it more generally be to flush between consequitive stanzas with different to/from or something like that?

  234. Flow

    Zash: hmm? "more generally"? Smack's approach is siimply "flush if there is no more to come"

  235. Flow

    Or what would be the advantage to flush based on from/to?

  236. SamWhited

    Flow: Probably just "we didn't know any better", but I have no idea; will advise.

  237. Zash

    Flow: I send you tree messages in a row, then an attacker sends a special ping (like in xnyhps post). The three messages would compress well, but the attackers ping would not affect that.

  238. Flow

    ahh got you

  239. Flow

    let me think, but i fear you are right

  240. Zash

    But it might be noticable that you got more than one similar message in a row

  241. Zash

    I don't know

  242. Zash

    Did anyone do any tests with a shared pre-negotiated dictionary?

  243. Zash

    As in, feed a string composed of a big bunch of common substrings likely to occur in common stanzas before feeding in the actual stanza to send

  244. daniel has joined

  245. daniel has joined

  246. Flow

    Zash: I think, in order for an CRIME-like attach to succeed when zlib/deflate sync flush is used as I desribed, the attacker would need to know which stanzas where bundled together in the same flush window (and therefore used the same dictionary).

  247. Flow

    *attack

  248. Flow

    furthermore, the attacker would need to time it so that his stanzas are bundled with the stanzas with the content he wants to determine

  249. Flow

    Seems hard but not impossible

  250. Ge0rG

    this is what happens when you mix control and data into one channel. People should have learned from the phreaking problems in the 70ies...

  251. Flow

    And throwing away the deflate dictionary if the from/to tuple changes would prevent that completely, just as throwing it away on the stanza boundary

  252. Flow

    Ge0rG: virtual control and data channel?

  253. Ge0rG

    Flow: yeah. and separate deflate dicts per JID

  254. Flow

    I wonder if random padding would prevent such an attack

  255. Kev

    Random dictionaries!

  256. Ge0rG

    Flow: random padding before or after compression?

  257. Ge0rG

    and how much padding should it be?

  258. Kev

    I do wonder how compression would be affected if every implementation lied to deflate and said that the current period-since-last-flush started with <presence type="unavailable"><show></show><status></status></presence><message and so on.

  259. Kev

    ISTM (not being a compression expert, that's more Dave's hobby) that you should be able to catch all the common cases.

  260. Flow has joined

  261. Ge0rG

    Kev: would that be a kind of a pre-defined dictionary?

  262. Kev

    Yes. I realise this isn't a new idea.

  263. Kev

    I'm just supporting Zash's suggestion above as interesting.

  264. Kev

    (And one I'd considered before)

  265. Ge0rG

    Kev: maybe we should just exclude payloads from compression?

  266. dwd has left

  267. Flow has joined

  268. dwd has left

  269. dwd has left

  270. dwd has left

  271. dwd has left

  272. Zash has joined

  273. Zash has left

  274. Zash has joined

  275. stpeter has left

  276. stpeter has joined

  277. stpeter has left

  278. Lance has joined

  279. SamWhited has left

  280. daniel has left

  281. xnyhps

    Zash: I think an easier way to achieve a similar thing is to just bind all the XML namespaces you might ever want to use on the initial stream header to a short prefix.

  282. Zash

    xnyhps: I've considered that too.

  283. daniel has joined

  284. Neustradamus has joined

  285. Neustradamus has left

  286. SamWhited has left

  287. Alex has left

  288. Alex has joined

  289. Lance has joined

  290. Flow has left

  291. Lance has joined

  292. Lance has joined

  293. SamWhited has left

  294. dwd

    http://wiki.xmpp.org/web/Board_and_Council_Elections_2015#XMPP_Council BTW.

  295. dwd

    Kev, zlib does have the dictionary stuff. I played with that once, for email transmission (using the message one was replying to as the compression dictionary).

  296. Lance has joined

  297. dwd

    Ge0rG, If you exclude payloads from compression, then basically what you're after is EXI in precompression mode, plus something other than deflate.

  298. dwd

    (And FTR, I got that from Arc Riley)

  299. intosi has left

  300. intosi has joined

  301. dwd has left

  302. dwd has left

  303. tim@boese-ban.de has left

  304. ralphm has left

  305. ralphm has left

  306. ralphm has left

  307. intosi has left

  308. intosi has joined

  309. stpeter has joined

  310. dwd has left

  311. ralphm has left

  312. SamWhited has left

  313. ralphm has left

  314. daniel has left

  315. daniel has joined

  316. ralphm has left

  317. Zash has joined

  318. daniel has left

  319. Martin has joined

  320. daniel has joined

  321. daniel has left

  322. daniel has joined

  323. Lance has joined

  324. SamWhited has left

  325. intosi has left

  326. intosi has joined

  327. intosi has left

  328. intosi has joined

  329. Ge0rG

    now that stpeter has published RFC7673, it's high time to publish my XMPP-DANE blog post... If somebody wishes to proof-read https://op-co.de/blog/posts/yax_im_dnssec/ I'm open for feedback

  330. stpeter

    Ge0rG: thanks, will read

  331. Ge0rG

    stpeter: an interesting question that arose today with Conversations' new SAN checking code. Are wildcards allowed in SRV-ID SANs?

  332. daniel has left

  333. daniel has joined

  334. waqas didn't know about DLV

  335. daniel has left

  336. waqas

    DLV sunsetting in 2016-2017.. is that because all TLDs will somehow be DNSSEC'ified by then?

  337. daniel has joined

  338. daniel has left

  339. daniel has joined

  340. SamWhited

    Yup, everything will also be IPv6 and there will be cake for all.

  341. daniel has left

  342. daniel has joined

  343. Ge0rG

    waqas: .IM won't be.

  344. Ge0rG

    Unless stpeter employs his magic super power of persuasion on Domicilium.

  345. Ge0rG

    but at least domicilium folks are friendly and respond, as opposed to StartCom.

  346. waqas

    SamWhited: I care more about the cake fwiw

  347. Ge0rG

    waqas: The cake is a lie.

  348. waqas

    :(

  349. waqas

    I haven't had cake in two weeks, largely because MattJ and people at the summit kept skipping dessert

  350. daniel has joined

  351. waqas has left

  352. Alex has left

  353. stpeter

    bbl....

  354. stpeter has left

  355. dwd has left

  356. intosi has left

  357. intosi has joined

  358. intosi has left

  359. intosi has joined

  360. Valérian has left

  361. Valérian has joined

  362. Valérian has left