XSF Discussion - 2018-08-29

Listen to how XMPP is pronounced: https://www.youtube.com/watch?v=fz0yDNwEydU&feature=youtu.be&t=495 It's like a message from God! :D

èxèmpaÿpeÿ

In regards to the list message "staleness of devices" When we are talking about 'messages' are we referring to stanza's, or specifically the <message/> stanza?

given that it’s omemo, we’re probably referring to OMEMO messages

vanitasvitae, ^

jjrh: an OMEMO <encrypted/> element

Which is encrypted for our device

Ah okay thanks for the clarification.

jjrh: :)

jdev seems down

flow: 3.2 Verification of <openpgp/> Content Recipients MUST verify that the signature is valid, that the signature's key corresponds to the sender's key,

seems up to me, lovetox

can we relax this a little bit

if a contact writes me offline messages, and i dont have the keys yet

then you have to wait until you have the keys, no?

this would mean caching all messages for later decryption IF i get the public key

signature validation sounds kinda important.

yes, but it doesnt has to be made instantly

especially not on first contact

i dont know how omemo does that, but i can read offline messages also without querying keys from the contact first

especially with other rules in the XEP like "blind trust on first contact" which seem to try and make this as easy and painless as possible

you can’t be sure those aren’t spoofed though

we are talking about first contact, if a attacker is a man in the middle, he can supply all the data he wants, it does not help me to query keys

signature verification makes only sense, if i verified that a fingerprint belongs truly to my contact

but if it’s an offline message, it’s unclear whether the attacker *still* has the power

it might be that they hijacked a device and were able to send a spoofed message

Why not mark the message as 'unverified'

but that access to the account was revoked?

lovetox, the contact also might have untrusted devices which intentionally do not have access to the GPG keys and are not used to send or receive GPG messages

hmm. but those devices could publish forged keys, so nevermind

!XSF_Martin, not allowed by the XEP

im not arguing that there cant be a case found where this rule would help to migitate a attack

the question is, is it worth the hassle

it does not help against man in the middle which is the biggest risk, we blind trust all keys, this alone is a HUGE risk

it boils down to: (a) who controls which keys are considered valid vs. who is able to send a message with this sender? and (b) why sign when verification is optional?

so why beeing so strict on this thing that does certainly not add a new big risk

jonasw, im not saying verification should be optional

anyways, gotta run

just something like, on first contact we can display the messages until we received the key

or something like that

i mean i can do this anyway, this XEP MUST is useless because it cant be enforced

it should be in the business rules or something, a suggestion with an exception or something like that

always verify, except you hadnt time to receive the key or something

what im saying, i will not implement this, its not worth the hassle to make the whole client async decrypt messages