XSF Discussion - 2024-08-04

Where can I read this "letter" you're all referring to?

http://soatok.blog/2024/08/04/against-xmppomemo/ just saw this. I'm far from a cryptographer, but some of the criticism sounded fair

The one about the too short changelog sounds fair. (if it's even true that the key length was altered) That person isn't known for a thorough analysis by what I've read lately from him

I don't lnow that person, but it did sound like they know crpyto, but not xmpp very much

omemo is an easy target anyway imo. in the sense that i doubt a lot of people choose to use something xmpp-based because of omemo

omemo is one of the weak parts at least with how it is currently deployed

E2E in Matrix is also very tedious and prone to annoyingly not decrypting from time to time. But E2E seems to be something that people look for.

i wasnt comparing it to matrix. but i agree at this point e2ee is desirable much more

MSavoritias fae.ve: I know you weren't. But that is the most popular FOSS alternative to XMPP, which is why I mentioned it as an example. (no need to dive deeper into Matrix here, I think)

right. makes sense

I think if XMPP gets E2EE that makes sense from crpyto-side, and is user friendly, that would help.

hook: I haven't looked at the analysis part and I have already seen the biggest strawman of the month: "If I find a problem in the latest draft of the specification, some will say that’s a non-issue because the spec is “experimental” and therefore should not implemented yet."

I mean, if your goal is only pure ethereal criticism, yeah that could possibly happen, otherwise constructive criticism is obviously welcome anywhere in the process

Yeah, I did find that one odd too. I mean, fair point about the changelog and the fact that many clients use an old version. But if you're criticising the spec do the new one and mention that an old one is actually more popular and point out the issues there too.

I totally get the point about having rationales for what is being done and better changelogs, yes

> otherwise constructive criticism is obviously welcome anywhere in the process Very true. But also not everyone in crpyto(graphy) is probably (using XMPP and hence) interested in active participation in XEPs. But that relates to a common issue of FOSS projects, about governance and (funding and PR and) gathering external contributions. Which is not an XMPP-specific issue.

their other blogpost <https://soatok.blog/2024/07/31/what-does-it-mean-to-be-a-signal-competitor> explains: > there have been a lot of opinions expressed and questions asked about messaging apps that have nothing to do with cryptographic security. > [...] It’s written from the perspective of someone whose career is in applied cryptography. which clarifies that their position does not take into account a lot of things I think a lot of us here value over "cryptographic perfection", such as self-hosting-ability, open/democratic standard writing processes, decentralisation/federation, permacomputing-friendliness, other "security" aspects than cryptography, etc.

nicoco: that matches my impression of them, too.

> http://soatok.blog/2024/08/04/against-xmppomemo/ > > just saw this. I'm far from a cryptographer, but some of the criticism sounded fair In short: "you're not a serious Signal competitor if you're not Signal" ↺

> In short: "you're not a serious Signal competitor if you're not Signal" 😅

not sure if i'm wrong but i always thought cryptogrphy is more like pure math than actual programming which is more like plumbing …

also security is not just cryptography tho is it …… just cut the cable …… no need to understand any math to do that ……

Trung: That is how I understand it too. But ultimately the this pure math algorithm needs to be plumbered into the protocols/servers/apps, so that is where the implementation can get mess, IIUC.

yeah i know there are people in here who actually don't use any omemo and still feel pretty secured

anyway, fox furry pictures look nice tho

The question about security is always about against which threat your dealing with.

fox is the only real threat

If you're E. Snowden maybe you have some specific needs, but it doesn't means that the whole planet need all those features and security details, and maybe you are more interested by some other features, decentralisation, standardisation, ecosystem is not something that you can find on Signal.

But still, I think that Signal is a needed tool and its good that we have it for those specific needs, but the whole chat platforms doesn't have to take it as a reference.

Trust is a big thing too. I would never be able to trust that signal messages are encrypted at all due to the distribution model

>> moparisthebest: My point is less about the active things, more about representing. We agreed to sign the open letter. as a non-eu organsiation. It would have a different pace if we also would have an European office I believe. >> >> >> That's an opinion and not true. I have always look at the organisation as a whole. Don't know where you take this from. And looking at the members background would potentially support that we should have an office in EU. > emus: let's be honest with ourselves, the letter will be ignored by the EU regardless. > > Also I'm not sure what you mean by the second bit, it's not an opinion or a slight at anyone or anything. I'm legitimately asking what opportunities are closed to the XSF now that will open up if it moves to EU. The XSF is not a contractor that takes on contracts, right? So if there are such things only available in EU that has no bearing on the XSF's decision. I was just making an example with the letter. Your statement, as I understood, "I would just care about the organisation", is an opinion and I stated against this. Yes, your questions are legitamite. We seem to not have encountered hard limits yet. But we should ask the members too if they had limitations due to having the office in US only. And even if there are no such things we will need to review the long-term situation of the XSF. ↺

i see nothing wrong with having office in Europe or North America or anywhere else on this floating rock

XSF exists mostly in the optic cable - here, in this MUC, and on the mail list. The such as legal whatever paperwork, sponsors, bank accounts, advertising campaign, limitless beer, physical office with nice looking girls making coffee for you, etc are nice-to-have

How do I request the most recent messages from MAM? There's the start field but that implies I know how recent the most recent messages are.

> The question about security is always about against which threat your dealing with. But threat modelling takes all the fun out of it. First, you write lots of security code, and then you decide that whatever it's protecting you against is *exactly* what everyone needs.

> How do I request the most recent messages from MAM? There's the start field but that implies I know how recent the most recent messages are. https://xmpp.org/extensions/xep-0313.html#filter-time - @kurisu, you just omit the end. And probably the start as well, though see also https://xmpp.org/extensions/xep-0313.html#filter-time

Oh. Last URI should be https://xmpp.org/extensions/xep-0313.html#query-paging

yeah, when I don' thave a last id I use start time today - 30 days

> > How do I request the most recent messages from MAM? There's the start field but that implies I know how recent the most recent messages are. > https://xmpp.org/extensions/xep-0313.html#filter-time - @kurisu, you just omit the end. And probably the start as well, though see also https://xmpp.org/extensions/xep-0313.html#filter-time Hm, if I just omit end and start and query this chat, I'm getting messages from 2010. I guess I could then page all the way to present day, but given how xmpp servers seem to like to limit their speed to pathetic 20kb or something like that, that's not very practical. That's why I wanted to load the most recent messages first. ↺

Speaking of security, I've been doing a tonne of updates to Metre of late, if anyone needs to host a component or do byzantine things with border controls. Or both.

So from what I understand the only option is try today-n days, then if that's not far back enough, try a longer period?.. well this hasn't really been thought through, has it...

kurisu, If only there were a section in the document entitles "Requesting the last page", that'd be pergfect for you.

oh

kurisu, But alas, we are all too stupid to think of that.

> Speaking of security, I've been doing a tonne of updates to Metre of late, if anyone needs to host a component or do byzantine things with border controls. Or both. Also vast amounts of updates to my fork of rapidxml. Though even I feel that working on an XML parser in 2024 feels a bit retro.

dwd: is there a config example for component hosting? Last I checked, which was years ago, this seemed slightly more complicated. At least more complicated than using a stub ejabberd config that I was already familiar with.

I often find myself in need of a simple component host and ejabberd always seemed a little overkill

Daniel, I'll add one now. Well, when I've done this next mega-push, anyway.

> XSF exists mostly in the optic cable - here, in this MUC, and on the mail list. The such as legal whatever paperwork, sponsors, bank accounts, advertising campaign, limitless beer, physical office with nice looking girls making coffee for you, etc are nice-to-have Its a legal representation in the EU we talk about, not an office or physical ↺

Well we would legally need an office address or something

singpolyma, Well, the XSF (in EU or US) needs a registered address, which is slightly different. You can get a registered address service for around 10 EUR per month, I think.

> Well we would legally need an office address or something Yes, but an office address does not need an actual office space. As long as (snail) mail can go there and eventually reach someone, it should be OK in most cases.

Daniel, Like this: https://github.com/dwd/Metre/blob/master/examples/component-hosting.conf.yml

Of course, if you checked years ago, that might pre-date my switching to YAML for config, so it'll look much saner as a result anyway.

hello!

i'm not sure if anyone has asked this already, but what was the rationale for truncating the HMAC in OMEMO?

i had a look at the PR that introduces the change and theres nothing there explaining why it was made

https://github.com/xsf/xeps/pull/932

is there a link to a mailing list discussion or something?

If people are suddenly concerned about truncated hashes can we stop using TLS 1.2 now? https://www.mitls.org/pages/attacks/SLOTH (from 2015)

are you a cryptographer?

No, neither is dumb blog guy from what I can tell lol

Maybe don't ad-hominem, moparisthebest

This PR does not suddenly introduce truncation

This has been in there since 0.4

Why it's truncated I can't tell you. But it always has been

Meh I call em like I see em, looks like nothing but bad faith signal shilling to me

Ever since we defined our own double ratchet

> Why it's truncated I can't tell you. But it always has been yes i am curious why this is ↺

Half his original claims were just flat out wrong

that’s a fair question. "but someone suddenly introduced it under the disguise of "clarifications" is wrong

> Why it's truncated I can't tell you. But it always has been the truncation reduces the size of the hash to less than that of sha1 ↺

and sha1 has known collision issues

the design decision itself is a bit odd because it compromises a great deal of security for very little bandwidth saving

The sha1 collision issues are not caused by size but by algorithm weaknesses

Signal says it's secure, so other than the unknown rational I don't see the issue.

The only real "attack" he mentions is the invisible salamander one which is possible in XMPP without any encryption and simply not an issue with how it's used in XMPP

> The only real "attack" he mentions is the invisible salamander one which is possible in XMPP without any encryption and simply not an issue with how it's used in XMPP this applies to the version of OMEMO used by conversations ↺

not the latest version

that’s also not true :-)

what isnt true?

that the problem doesn’t exist in the latest spec

My point is hash truncation has been known to be a problem in TLS 1.2 since at least 2015 and everyone is comfortable enough still using that...

The invisible salamander problem, or truncation one?

if A sends message in a group to B and C but B and C see different messages is a problem to you then you have the same problem in twomemo

while i havent read the context of the TLS thing, if its as bad as you say, why have 2 insecure protocols instead of 1

> The invisible salamander problem, or truncation one? the style of the attack that invisible salamander does

> The invisible salamander problem, or truncation one? the truncation one is in the latest version ↺

What the wannabe-cryptographer doesn't see is that it literally doesn't matter how secure signal's end2end encryption is when they fully control all the ends and can update them silently outside of user's control

i dont see what that has to do with xmpp

mcneb10: the truncation one isn't a security problem though, as the blog post in question explains with links to rationale from signal

I agree I'd like us to document why it was done ✏

>> The invisible salamander problem, or truncation one? > the style of the attack that invisible salamander does How so? From what I understand that's an AES-GCM mode thing, which twomemo doesn't use ↺

you don’t need any fancy crypto attacks do pull of the attack

if A controls the group chat (which is not uncommon in xmpp) then simply send different messages to B and C

> I agree I'd like us to document why it was done yes for something as important as cryptography every design decision should be explained ↺

there is nothing in omemo that would prevent that

(I actually wonder if there is something in Signal to prevent that)

not using aes-gcm is completely irrevelant

> if A controls the group chat (which is not uncommon in xmpp) then simply send different messages to B and C True, but I think if you're a normal participant with no such control this isn't possible? ↺

not to my knowledge. but i don’t think it matters if such an attack is a problem for you

because the regular user won’t check who hosts the group

It can be with multiple bodies and different language tags

either this is a problem to you - then you can’t use twomemo either - or it isn’t

to me it isn’t. but whatever

I thought no client even indicated that but Daniel told me Conversations does :) that's something

maybe we should convince the "are we omemo yet" site to change its mission to "are we omemo:2 yet"

> Half his original claims were just flat out wrong Claiming that Conversations rolls its own PGP implementation is amusing ↺

and btw i'm still eager to hear what Signal does to prevent that sort of attack

areweoxandmlsyet.com

MLOX?

Daniel: they control all the chats. So no one could do the attack you propose but signal themselves I guess

oh sure. and signal are trusted?

> and btw i'm still eager to hear what Signal does to prevent that sort of attack They don't let normal people host their own server :) ↺

Of course!

singpolyma: nnnnnoooooo "cryptographers" like that guy hate PGP or people "rolling their own crypto" except for signal they are allowed

> oh sure. and signal are trusted? Yeah I think that's the premise of any signal user ↺

moparisthebest: well, mls has the advantage that there is a spec so we don't have to roll our own

so, is there anywhere i can find the omemo mailing list?

so i can know the design decisions?

we don’t have our own list; we just use standards@xmpp.org

are there any efforts going on to implement newer omemo versions?

Some clients already did, so yes

in the mainstream clients?

There isn't a list of mainstream and non mainstream clients and also no official stats

iirc there is a branch for dino and gajim might be working on it

thats good

and kaidan has it. which i guess isn’t 'mainstream'

theres this other client called moxxy that implements it as well

but its still under heavy development

in mam's <after>$value</after>, $value is apparently not the message id, rather it's the id of <result>. I'm wondering why these are different? How does this even work internally, especially given that >There is no concept of an "open query", and servers MUST be prepared to receive arbitrary page requests at any time. Is a server supposed to store a constant result/@id for each message?

Libervia is also on twomemo iirc

kurisu, <message id=""> can't be trusted to be globally unique, so the archiving entity has its own scoped IDs

> Is a server supposed to store a constant result/@id for each message? https://xmpp.org/extensions/xep-0313.html#archives_id

What if, for example, a user downloaded part of the message archive, then on another day he scrolls up and the client needs to download more from the server. For this case, is a client supposed to store the result/@id value along with the stored messages in the database to set it in <before>?

> kurisu, <message id=""> can't be trusted to be globally unique, so the archiving entity has its own scoped IDs I thought that was what <stanza-id> was supposed to solve?... ↺

> I thought that was what <stanza-id> was supposed to solve?... It is, as explained by the link above, it is set by the archiving entity ↺

> What if, for example, a user downloaded part of the message archive, then on another day he scrolls up and the client needs to download more from the server. For this case, is a client supposed to store the result/@id value along with the stored messages in the database to set it in <before>? Yes, store the archive-scoped id. ↺

> It is, as explained by the link above, it is set by the archiving entity But then it's not what's used in <after>, <before> etc. Why? ↺

Yes it is

The <stanza-id@id> is the same as the <result@id>

and what you use in RSM

hmm, actually for some reason I'm not seeing stanza-ids sometimes at all. E.g. your message was sent to me from the archive as: ``` <message to='kurisumakise@draugr.de/test' from='xsf@muc.xmpp.org' xmlns='jabber:client'> <result queryid='1' id='2024-08-04-8a8816c6a6ab6896' xmlns='urn:xmpp:mam:2'> <forwarded xmlns='urn:xmpp:forward:0'> <delay stamp='2024-08-04T17:59:41Z' xmlns='urn:xmpp:delay'/> <message id='13360be6-9ba4-4d80-bf34-26a9fc5f1036' type='groupchat' xml:lang='en' from='xsf@muc.xmpp.org/Zash' xmlns='jabber:client'> <body>The <stanza-id@id> is the same as the <result@id> </body> <occupant-id id='UhzLgfB9rCyoTYlCG2qKE1RfkVD9Fkbt7kcxDoc29iQ=' xmlns='urn:xmpp:occupant-id:0'/> </message> </forwarded> </result> </message> ``` With no stanza-id at all. It seems to contradict that paragraph about "MUST add an <stanza-id/> "

In query results it's the <result @id>

oh my goodness

It would be extremely redundant to add it a second time

Especially with clients adding the <message id=> also into <origin-id>

If you watch live traffic (not query results) you will see <stanza-id> carry the archive id

~Yeah, xml is already all about redundancy. ~ Just seems counter intuitive to see the same value for the same message in a different place

> If you watch live traffic (not query results) you will see <stanza-id> carry the archive id got it, thank you ↺

It seems that the "Atom" feed on the blog https://xmpp.org/blog/ is actually a RSS 2.0 feed, not an Atom one

cal0pteryx