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 :)
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
Flowhas left
ralphmhas left
ralphmhas left
dwdhas left
Martinhas left
SamWhitedhas left
Willhas left
dwdhas left
Zashhas joined
dwdhas left
SamWhitedhas left
Kevishhas left
intosi has left
intosi has joined
danielhas left
ralphmhas left
ralphmhas left
ralphmhas left
stpeter
Tobias: seems like it, yes
danielhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
Flowhas joined
tim@boese-ban.dehas left
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.
dwdhas left
Zashsilently curses whoever made him notice 'then' vs 'than'
Flow
Zash: uh, thanks for pointing this out :)
SamWhited
Flow: I think we're doing it on stanza boundaries (for reasons which I don't remember), but that makes sense.
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.
Zash
Wouldn't it more generally be to flush between consequitive stanzas with different to/from or something like that?
Flow
Zash: hmm? "more generally"? Smack's approach is siimply "flush if there is no more to come"
Flow
Or what would be the advantage to flush based on from/to?
SamWhited
Flow: Probably just "we didn't know any better", but I have no idea; will advise.
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.
Flow
ahh got you
Flow
let me think, but i fear you are right
Zash
But it might be noticable that you got more than one similar message in a row
Zash
I don't know
Zash
Did anyone do any tests with a shared pre-negotiated dictionary?
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
danielhas joined
danielhas joined
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).
Flow
*attack
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
Flow
Seems hard but not impossible
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...
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
Flow
Ge0rG: virtual control and data channel?
Ge0rG
Flow: yeah. and separate deflate dicts per JID
Flow
I wonder if random padding would prevent such an attack
Kev
Random dictionaries!
Ge0rG
Flow: random padding before or after compression?
Ge0rG
and how much padding should it be?
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.
Kev
ISTM (not being a compression expert, that's more Dave's hobby) that you should be able to catch all the common cases.
Flowhas joined
Ge0rG
Kev: would that be a kind of a pre-defined dictionary?
Kev
Yes. I realise this isn't a new idea.
Kev
I'm just supporting Zash's suggestion above as interesting.
Kev
(And one I'd considered before)
Ge0rG
Kev: maybe we should just exclude payloads from compression?
dwdhas left
Flowhas joined
dwdhas left
dwdhas left
dwdhas left
dwdhas left
Zashhas joined
Zashhas left
Zashhas joined
stpeterhas left
stpeterhas joined
stpeterhas left
Lancehas joined
SamWhitedhas left
danielhas left
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.
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).
Lancehas joined
dwd
Ge0rG, If you exclude payloads from compression, then basically what you're after is EXI in precompression mode, plus something other than deflate.
dwd
(And FTR, I got that from Arc Riley)
intosi has left
intosi has joined
dwdhas left
dwdhas left
tim@boese-ban.dehas left
ralphmhas left
ralphmhas left
ralphmhas left
intosi has left
intosi has joined
stpeterhas joined
dwdhas left
ralphmhas left
SamWhitedhas left
ralphmhas left
danielhas left
danielhas joined
ralphmhas left
Zashhas joined
danielhas left
Martinhas joined
danielhas joined
danielhas left
danielhas joined
Lancehas joined
SamWhitedhas left
intosi has left
intosi has joined
intosi has left
intosi has joined
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
stpeter
Ge0rG: thanks, will read
Ge0rG
stpeter: an interesting question that arose today with Conversations' new SAN checking code. Are wildcards allowed in SRV-ID SANs?
danielhas left
danielhas joined
waqasdidn't know about DLV
danielhas left
waqas
DLV sunsetting in 2016-2017.. is that because all TLDs will somehow be DNSSEC'ified by then?
danielhas joined
danielhas left
danielhas joined
SamWhited
Yup, everything will also be IPv6 and there will be cake for all.
danielhas left
danielhas joined
Ge0rG
waqas: .IM won't be.
Ge0rG
Unless stpeter employs his magic super power of persuasion on Domicilium.
Ge0rG
but at least domicilium folks are friendly and respond, as opposed to StartCom.
waqas
SamWhited: I care more about the cake fwiw
Ge0rG
waqas: The cake is a lie.
waqas
:(
waqas
I haven't had cake in two weeks, largely because MattJ and people at the summit kept skipping dessert