XSF Discussion - 2015-10-15

any XEP editor around?

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

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

Tobias: seems like it, yes

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.

Zash: uh, thanks for pointing this out :)

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

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.

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

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

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

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

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.

ahh got you

let me think, but i fear you are right

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

I don't know

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

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

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

*attack

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

Seems hard but not impossible

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

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

Ge0rG: virtual control and data channel?

Flow: yeah. and separate deflate dicts per JID

I wonder if random padding would prevent such an attack

Random dictionaries!

Flow: random padding before or after compression?

and how much padding should it be?

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.

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

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

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

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

(And one I'd considered before)

Kev: maybe we should just exclude payloads from compression?

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.

xnyhps: I've considered that too.

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

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

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

(And FTR, I got that from Arc Riley)

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

Ge0rG: thanks, will read

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

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

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

waqas: .IM won't be.

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

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

SamWhited: I care more about the cake fwiw

waqas: The cake is a lie.

:(

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

bbl....