XSF Discussion - 2018-08-16

Ugh, https://infosec-handbook.eu/blog/xmpp-aitm/

They’re mostly right, but I dislike their conclusions.

Link Mauve: they also had a rant about how bad XMPP is, recently

https://infosec-handbook.eu/blog/federation-myths/

Ge0rG, this is another.

Link Mauve, "Furthermore, he is convinced that most XMPP server and client software is more a leisure project than secure software." - there's at least three companies working with XMPP in high security environments.

Uh, worth reading?

To be fair the companies you are talking about aren't the companies and products most end users are using

But still at least ejabberd and Conversations are products created by for profit entities

> Uh, worth reading? Not really

> Links > * How to use Signal more privacy-friendly

Uuuuuhu

> solution, don't use Signal

> solution, stop doing those computer things and become potato farmer

jonasw: potato seeds are generticaly manipulated by Monsanto to not reproduce after the first generation, forcing you to buy new seeds from them

Plant potato, get more potato

Still don't quite understand why "Don't trust an XMPP server operator, they can monitor your traffic really easily!" can be combined with "Use this centralized service, because the admins and hosting providers are totally trustworthy."

dwd: You dare question our lord and saviour, Moxie?! /s

Something something praise be crypto-jesus

never question Father Moxie

Well, right. That's why pretty much every *other* cryptographer is working on MLS.

and the Signal centralized backend deployed on AWS instances :p

but it's "Snowden Approved ©"

and Schneier approved(?)

Yeah, because a guy who dumped a load of stuff he hadn't even read onto a bunch of journalists is a good source of judgement.

The holy trinity giveth unto us Signal

by the way, the centralized-xmpp-based-omemo Cryptocat client is not maintained anymore ? https://github.com/cryptocat/cryptocat

dwd, (being devil’s advocate): "because we can deploy useful e2ee"

jonasw, Sure, but the remaining problems still exist - anyone reading the cleartext Signal traffic can read out the routing info.

edhelas: does that surprise you given the three preceding iterations of that project?

dwd: wait, what?

Zash: Facebook paid TWO MILLION DOLLARS to get moxie's Stamp Of Approval. It must be good!

Zash: if your "wait, what" relates to Signal: the Signal admins can access exactly the same kind of metadata as your XMPP server admin, except with phone numbers instead of JIDs. But they Totally Promised Not To Do It.

so this is fine

I read what dwd wrote as an implied lack of transport encryption

Zash: I think "cleartext Signal traffic" was supposed to mean the post-decryption stream

Noise?

wouldn't that be pre-decryption?

Were they the funny people who named their transport protocol "Noise"?

Zash: drink some more coffee. Or drink less, if you've had some today.

Post-lunch nap perhaps

Zash, No, I did mean inside the service. I assume it runs TLS etc.

dwd: I have this feeling that they invented their own TLS and named it Noise

With that bunch, that's entirely possible.

http://noiseprotocol.org/index.html hmmmmm, doesn't say Signal anywhere?

But WhatsApp

https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/ - this is so similar to XMPP

DNS, complex? But, but, it's being HTTP&JSON-ified! That's the simplest thing evar!!!

Zash: take your nap already

XSF Board Meeting | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

0. Welcome

Who do we have?

I'm back from vacation.

o/

welcome back

(MattJ is always here if you mention him 😛 )

😰

*tap* *tap* is this thing on?

Hey

😅

Sorry, was temporarily distracted by the doorbell :)

Quorum, yay

Agenda items?

I don't have any

I haven't looked at Trello in a while

at what point are we going to send someone over to Martin's house to check if he's OK?

(not you, Martin. The other Martin)

He did reply to my email fairly promptly, so he's "around"

so no need to send a SWAT team?

Didn't we discuss this back in June?

21, specifically

Probably

Any updates on your side MattJ?

No, the only thing on my side is GDPR, and I'm afraid I've not had time to work on it

Now vacation is over and summer is coming to an end, we should be able to get back in motion.

Yes, hopefully

Just before the end of the term :)

which reminds me: should we start looking for the next Board?

That was going to be my only thing for today. Ask Alex when he wants to start that process.

We can already start poking people for interest.

sounds like a plan

maybe we should also curate our to-do list, see what things we can reasonably expect to get done this term, and what not

I'll have a look at it for next week.

Anything else?

And, while on the subject:

Nothing else from me

Should we consider putting in place a system where we do not replace the entire board each year?

have two-year terms, staggered - something like that?

I'm hoping that that'll prevent ramp-up and shut-down overhead, by making it more of an ongoing process.

Not sure. I don't think it has been a problem before.

All boards I was part of had overlap

ralphm, Yes, but not by design, and there's always a feeling that Board can't do anything that goes beyond its term.

That's a good point. This would require changes to our Bylaws, though. Not sure if we can do that before these elections.

oh, I'm not in a hurry

ralphm, I have occasionally wondered about staggered terms, or an "executive team" that actually does the work, that can be recalled by subsequent boards.

shall I post on the members list, see if there's support or not?

We really don't have any kind of executive team

dwd: well, yeah, but since we currently don't even have an Executive Director, we'd to figure out what that all means.

Guus: please do.

k

Ok. My last thing was more of a note: FOSDEM has posted a CfP for 2019. Dates are February 2 and 3.

ah, someone should kick SCAM in action

So was penciling in Jan 31 and Feb 1 for our own stuff.

Sounds good. I've marked it on my personal calendar

Ok.

Cya next week!

XSF Discussion | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

So, I've been debugging XEP-0198 support. And I tried - because it seemed easiest - including XEP-0198 data on the stanza itself, as namespaced attributes. Gajim seemed to ignore it - anyone any idea if any clients would choke?

(I was doing this as debugging info I was *hoping* would be ignored, mind...)

I still can’t understand how clients could choke on this proper usage of XML, while we are already doing it e.g. for @xml:lang.

Dave Cridland: that smells of protocol abuse. But if you give me credentials / IBR, I can test yaxim

Link Mauve, We've avoided namespaced attributes in general because people do screw it up, or at least have historically.

I’d really like to see data on that.

Please deploy that in the wild. :)

I also need to debug an SM anomaly that I've encountered, where messages get duplicated on resume. Sometimes.

Link Mauve, They're a bit of a weird one, in terms of XML, since <x xmlns='foo' attr='blah'/> is entirely different from <a:x xmlns:a='foo' a:attr='blah'/>.

Ge0rG, duplicates send *after* resume?

Ge0rG, This ought to help track that one down. I'll throw you my IBR-enabled test server's details.

Dave Cridland, care to share why those elements are different?

Dave Cridland, first one would be equivalent to <a:x xmlns:a='foo' attr='blah'/>, because non-prefixed attributes are in the null namespace.

flow, ↑

But you can perfectly have them in other namespaces.

flow, As Link Mauve says. But thanks for being an exemplar case of not understanding the things.

<x xmlns='foo' xmlns:b='bar' b:attr='baz'/> works, but it’s a totally different element.

And thus you can also have <x xmlns='foo' xmlns:b='bar' attr='blah' b:attr='baz'/>, with no conflict.

Link Mauve, I'm not sure that a non-prefixed attribute is in any namespace at all, as such.

Which is equal to <a:x xmlns:a='foo' xmlns:b='bar' attr='blah' b:attr='baz'/>.

Link Mauve, So you can't, for example, say <x xmlns='foo' xmlns:null='' null:attr=blah'/>

Indeed.

Instead of “the null namespace” I should have said “no namespace”, but null is how this is represented at least in JS and Java.

Link Mauve, Right, but "attr" is "The attr attribute of x", whereas your "b:attr" is the "attr attribute of the bar namespace".

Hmm…

But in any case, corner-cases like <a xmlns:a='a' xmlns:b='a' a:a='bar' b:a='foo'/> can easily slip through.

Since that XML happens to be legal if you're not processing namespaces, but illegal if you are.

Why? :/

Ah, missed that both are the same namespace.

Link Mauve, Right.

But are there really XML libraries which fail on that?

I’d expect they to be fixed by then.

Link Mauve, I'd fully expect that XML to traverse most servers.

possibly depending on the layer where the XML is embedded. Not all intermediate hops parse each and every part of the stanza

flow, Right. Or at least, not to the namespace level.

% nc 82.226.255.187 5222 <?xml version='1.0'?><stream:stream xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en' xmlns='jabber:client' to='linkmauve.fr'> <?xml version='1.0'?><stream:stream xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en' from='linkmauve.fr' id='a8ccb26b-51b5-4a48-b1cb-ea4734f61a7f' xmlns='jabber:client'><stream:features><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'><required/></starttls></stream:features> <a xmlns:a='foo' xmlns:b='foo' a:coucou='abc' b:coucou='def'/> <stream:error><not-well-formed xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error></stream:stream>

At least Prosody correctly rejects it.

flow: yes, because smack3+0198 was miscounting.

Link Mauve, even if it is embedded deep down in an extension element within a stanza?

Link Mauve, I'd expect Prosody to, because it's using Expat underneath, right?

Correct

Link Mauve, But ejabberd uses RapidXML, as does Metre. I'm not sure about Openfire actually - but it wouldn't surprise me if it passed them through unscathed.

ejabberd uses Expat.

I thought so. I thought dwd was implying they switched

Holger, Oh, I thought the new stuff was using an Erland-wrapped RapidXML?

Erlang, even.

dwd: Nope still Erlang-wrapped Expat, I'm not aware of attempts to switch.

There was a major rewrite of the wrapping itself, which is now mostly in C.

Ah! MongooseIM, not ejabberd. exml is now RapidXML.

But confusingly, I don't think they use my fork.