XSF Discussion - 2019-08-19

Is there a simple C++ XMPP library that lets me interact with raw XML?

I wan't to creat an application that runs on a microcontroller with only 500kByte of ROM

COM8, I used libstrophe or libcouplet in the past

(both are C)

(but should be perfectly usable with C++)

example usage in my project: https://github.com/horazont/hint/blob/devel/host/src/xmppintf.c

Thanks. will have a look at it

COM8: http://deusexmachinae.se/dxmpp/ was written with IoT stuff in mind, but not sure it's minimalistic enough for your use case.

Holger: dxmpp looks also interresting. Thanks.

Sigh. Prosody will send a cancel/not-acceptable if you are not in a MUC, Biboumi will send a modify/not-acceptable, and ejabberd will just send a sender-less message into the MUC if you happen to be an admin.

Consistency, I want you back.

back?

Right.

If I'm reading https://xmpp.org/rfcs/rfc6120.html#stanzas-error-syntax right, `modify` is only about the data, not about your own state.

I'd listen to reasoned argument about whether 'cancel' would better be 'modify', but I am currently unconvinced that 'modify' is correct

MattJ: you can re-try sending the message after joining the MUC

True

I remember a proposal about an application-defined condition of <not-an-occupant> of sorts.

For me the semantics of the error types are generally most easily distinguished by the appropriate UI - e.g. 'modify' would re-show whatever dialog a user submitted that caused an action

In this case I guess just the input box

This feels slightly related to cancel/recipient-unavailable that mod_smacks sends when the session dies.

MattJ: I recently added logic to yaxim to mark the message as "not yet sent" and to rejoin the MUC in those cases.

but only on cancel/not-acceptable, not on modify

maybe Holger knows the right error bounce if you send a message while not being in an ejabberd MUC?

Also, the RFC has to say: 'The intended recipient is temporarily unavailable, undergoing maintenance, etc.; the associated error type SHOULD be "wait".'

MattJ: the RFC also proposes "modify" for not-acceptable.

Ge0rG: Yes ejabberd returns modify/not-acceptable (as per the spec).

MattJ: ^

Holger: it's only a SHOULD in the spec.

If we deviate from the spec we can certainly fix that

And modifying the message _data_ won't fix the issue

I disagree with most cases of "only a SHOULD"

Ge0rG: I'm slowly getting used to having to justify why on earth ejabberd adheres to SHOULDs :-)

Question: Servers are expected to validate stanza syntax for stanzas they route, but does anyone actually extend that to doing the xml:lang rule checking for duplicate bodies etc.?

Holger: not long ago I violently complained about ejabberd implementing a MAY.

I do remember :-)

Kev: ejabberd doesn't, FWIW. (It only checks the validity of the xml:lang value itself.)

Ta.

how about auth/not-acceptable, Ge0rG? :D

jonas’: is that a serious proposal? 😜

Ge0rG, partly

jonas’: you could submit a PR to 0045 with the new custom error condition.

I could indeed

jonas’: will you?

not today

I have an aioxmpp release to make

Technically, a message could also be rejected by a MUC for an actual policy violation, right?

It would be modify/not-acceptable in that case.

So I think cancel/not-acceptable is a cleaner way of signalling "you are not in the MUC".

But less clean than cancel/custom-condition/not-an-occupant

+1

Was it MattJ who said type=auth made sense?

I don't think so

it was jonas’ and it wasn't very serious.

Well if you consider a join to be almost like auth if you squint the right way

Maybe we really just need MUC-Push

ITYM MIX

Yeah, let's reinvent all of our protocols without learning from past errors.

I got the impression that MIX at least attempts learn from them

From a subset of them, I'd say.

From where I'm looking, it picks a handful of problems with MUC, and fixes them by exchanging them with other design trade-offs

Mostly with a significantly increased complexity.

We are solving complex problems

the problem space is so complex that there is no one-size-fits-all solution

Agreed

(what mattj said...)

fippo: right. And forcing all the problems into one solution has proven to end up badly in the past.

i find MIX to be easier than MUC with the shit loads of hacks you need to implement to make it bearable

Daniel: only because you don't know yet the shitload of hacks you need to make MIX bearable

Wait a decade and say that again

Ge0rG, well mix is not stable yet so we could fix them before they become hacks

Requirements change. Hacks accumulate.

Daniel: adding MIX rooms to your roster is already a huge hack.

proxy JIDs... another hack

handling of intermittent s2s failures: a hack waiting to happen

well we decided to not do that

putting it in the roster

the xep just doesn’t know that yet

oh, where did I put my "told you so" stamp?

what part?

MIX has all the signs of "design by committee"

MUC doesn't?

Daniel: the MIX-in-roster part

that we are going to decide not to do that?

Zash: hm..

Daniel: that it's a very dumb idea.

yes; that's why we decided to get rid of it

When did you? And who's "we" anyway?

ah, Summit

Heh, my first opposition to MIX in Roster was three years and two days ago.

Delayed happy opposition day!

I'm not sure whether to be glad or sad.

hm

It was brought to my attention (as author of XEP-0414) that the section "Analysis of [Hash function use in] Existing XMPP Extensions" was lost in the split of XEP-0300 and XEP-0414

I am inclined to remove the (dangling) reference to that section from XEP-414 entirely

but I could link it to an older version of XEP-0300 instead

does anyone here happen to have a strong opinion on that one?

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

No strong opinions here. Maybe a "hmm, not sure" from me.

those who have implemented XEP-0027 (Current Jabber OpenPGP Usage): my reading of the XEP indicates that messages are either signed or encrypted, but never both

this doesn’t make sense to me

but the XEP lacks a writeup on how an signed+encrypted message would look like

You can just have both elements I think.

In any case you only encrypt/sign the body/status.

but it’s not specified whether you sign or encrypt first

it’s not specified whether the raw or the armored encrypted output is signed (if encrypt-then-sign is used)

Yeah, maybe I'm wrong: “It does not enable both signing and encryption of a stanza, only signing of the presence status and encryption of the message body.”

that’s kind of meh

is it really how it’s deployed in the wild?

I think the general opinion of it isn't high.

it seems to be the way how openpgp is implemented nowadays though

Also replay attacks

yeah

that’d be my concern

but apparently that’s the case indeed

Conversations uses ACTION_ENCRYPT for the message

if I’m reading the code right

https://github.com/open-keychain/openpgp-api/blob/master/openpgp-api/src/main/java/org/openintents/openpgp/util/OpenPgpApi.java#L119 https://github.com/siacs/Conversations/blob/master/src/main/java/eu/siacs/conversations/crypto/PgpEngine.java#L50 ✏

there is a reason to encrypt but not sign, repudiation, ie "what? I didn't send that and you can't prove that I did!!!!"

but there is also value in encrypt + sign if you don't need that property

I am always suprised that xep27 is still gets implemented given the amount of serious issues it has

(context why I’m asking: feature request for xep-0027 support against aioxmpp)

jonas’: sometimes it's best to reject feature requests.

sometimes, but then again, we’d just provide the schema declarations anyways

e2ee implementation is for now out of scope for aioxmpp

flow, like what?

I mean it's basically the same as encrypted but not signed email, it can be useful, you just have to know what you are getting

moparisthebest, like the ones mentioned at https://xmpp.org/extensions/xep-0027.html#security (and there are probably more)

those aren't really "security issues" as such though

and "it can be useful" is probably true, but I'd argue most xep27 users, would expect signed and encrypted messages

the encrypt only use case is rarely useful

jonas’, this be why '27 is discouraged and OX is a thing I believe

for example I used to have my various servers send me alert/cronjob emails etc pgp encrypted, and then I switched to xep27 xmpp messages, same (actually slightly better) security properties

but yea if users think they are getting something else, that's their problem

moparisthebest: that doesn't sound like you had a requirement to not sign.

other than I didn't generate PGP keys for my servers no

well it was signed before, so it is true that is not a step back. But if your use case is human-to-human interaction, then "encrypt only" is not what you ever want to do with OpenPGP

*wasn't signed before

FWIW, I’m going to tack: .. warning:: Please see the security considerations of :xep:`27` before making use of this protocol. Consider implementation of :xep:`373` instead. on all the things touching XEP-0027 in aioxmpp

flow, I have in the past intentionally sent unsigned but encrypted emails

but those are very *very* rare cases

probably less than five since I started to use gpg

and I don’t think it’s the default in any way, and I *do* think that an E2EE protocol which does not support signing of messages *at all* is definitely a prolbem

I can't imagine that the average joe user would want to send unsigned but encrypted mails

true

me neither

jonas’, what was your intention sending unsigned but encrypted?

anti-govt activists would though

Average joe actually doesn't think about encryption at all.

though I'd accept an argument they should just use OTR instead

flow, I made statements which I wasn’t sure I wanted to have signed with my public identity. ✏

moparisthebest: I'm sure they could just create a throw away key

moparisthebest, anti govt activists shouldn't use e-mail (and probably xmpp) at all for their communication

jonas’, hmm, I don't know the exact case, but that is usually a sign to sleep over the mail another day until you send it ;)

flow, I had done that step already

Is memberbot offline?

Ah it's fine now

https://wiki.xmpp.org/web/Jonathan_Siegle_Application_2019 Is he around here somewhere? I've never actually heard of him, didn't even know he was running xsf machines

(or maybe it's just that I don't know the realname)

No, he's very much in the background these days