XSF Discussion - 2015-10-15

  1. Tobias

    any XEP editor around?

  2. 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 :)

  3. 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

  4. stpeter

    Tobias: seems like it, yes

  5. 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.

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

  7. Flow

    Zash: uh, thanks for pointing this out :)

  8. SamWhited

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

  9. 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.

  10. Zash

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

  11. Flow

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

  12. Flow

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

  13. SamWhited

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

  14. 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.

  15. Flow

    ahh got you

  16. Flow

    let me think, but i fear you are right

  17. Zash

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

  18. Zash

    I don't know

  19. Zash

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

  20. 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

  21. 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).

  22. Flow


  23. 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

  24. Flow

    Seems hard but not impossible

  25. 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...

  26. 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

  27. Flow

    Ge0rG: virtual control and data channel?

  28. Ge0rG

    Flow: yeah. and separate deflate dicts per JID

  29. Flow

    I wonder if random padding would prevent such an attack

  30. Kev

    Random dictionaries!

  31. Ge0rG

    Flow: random padding before or after compression?

  32. Ge0rG

    and how much padding should it be?

  33. 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.

  34. Kev

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

  35. Ge0rG

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

  36. Kev

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

  37. Kev

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

  38. Kev

    (And one I'd considered before)

  39. Ge0rG

    Kev: maybe we should just exclude payloads from compression?

  40. 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.

  41. Zash

    xnyhps: I've considered that too.

  42. dwd

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

  43. 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).

  44. dwd

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

  45. dwd

    (And FTR, I got that from Arc Riley)

  46. 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

  47. stpeter

    Ge0rG: thanks, will read

  48. Ge0rG

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

  49. waqas didn't know about DLV

  50. waqas

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

  51. SamWhited

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

  52. Ge0rG

    waqas: .IM won't be.

  53. Ge0rG

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

  54. Ge0rG

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

  55. waqas

    SamWhited: I care more about the cake fwiw

  56. Ge0rG

    waqas: The cake is a lie.

  57. waqas


  58. waqas

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

  59. stpeter