Re: [Standards] [XEP-0384] OMEMO: MUST silently discard [..]
On 2018/12/01, forenjunkie wrote: > Hi, > As Daniel wrote, MUST is probably to strong here, it is enough to mention > that it can lead to problems if you dont discard such messages. As I am not especially knowledgeable on OMEMO or the implications yet, I would appreciate if somebody PR'd against the XEP to change this, and provide some kind of rationale. If it's just a matter of s/MUST/SHOULD/ for these 3 cases, or even MAY, I can do this. > If you have a client that always shows the user if a decryption fails, this > also means you need a client that has absolute perfect deduplication in any > kind of scenario. I would prefer to send too much than not enough. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [XEP-0384] OMEMO: MUST silently discard [..]
Hi, As Daniel wrote, MUST is probably to strong here, it is enough to mention that it can lead to problems if you dont discard such messages. If you have a client that always shows the user if a decryption fails, this also means you need a client that has absolute perfect deduplication in any kind of scenario. Otherwise you show the user he misses a message when in reality he doesnt miss a message. Pepare for many Bug reports. At the time the XEP was written, even mam:2 was not widley deployed, so saying any client can have perfect deduplication was far fetched. Nobody wants to use a standard that constantly gives the impression you miss messages when there is no problem at all. Also there are still quite a few mam:1 servers out there, so good luck deduplicating if the message is encrypted and there is no stanza-id :) Regards Philipp ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [XEP-0384] OMEMO: MUST silently discard [..]
Am Sa., 1. Dez. 2018 um 15:08 Uhr schrieb Maxime Buquet : > > Hi Standards, > > When trying to implement OMEMO support in poezio, I came across a few > points that make me shiver like chalk on blackboard each time I read > them. > > All 3 points are in > https://xmpp.org/extensions/xep-0384.html#usecases-messagesend. > > > When an OMEMO element is received, the client MUST check whether there > > is a element with an rid attribute matching its own device ID. > > If this is not the case, the element MUST be silently discarded. This I don’t do and I don’t think it makes sense. Instead I display a 'message was not encrypted for this device' > > > If the element's contents are a SignalMessage, and the client has a > > session with the sender's device, it tries to decrypt the > > SignalMessage using this session. If the decryption fails or if the > > element's contents are not a SignalMessage either, the OMEMO element > > MUST be silently discarded. > > > If the OMEMO element contains a , it is an OMEMO message > > element. The client tries to decrypt the base64 encoded contents using > > the key and the authentication tag extracted from the element. > > If the decryption fails, the client MUST silently discard the OMEMO > > message. > > Can anybody explain why as a library dev I would want to silently > discard messages and not let the end-users know they just lost messages? > So that they can then take appropriate actions, (e.g., ask the other > party to resend, file a bug in the library). I think a lot of the other discard rules originally come from the problem that through bad MAM catchup we might received messages twice and won’t be able to decrypt them another time. So in some cases 'discard them after decrypt failure' is based on the assumption that we have already decrypted them once. But I agree that this rule in that broad wording doesn’t make sense and should rather read; If you detect that a message has been decrypted already discard it. I think when OMEMO was written we didn’t have stanza-id and other types of more or less reliable dedup. Not excusing the standard here; just giving you some background. cheers Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] [XEP-0384] OMEMO: MUST silently discard [..]
Hi Standards, When trying to implement OMEMO support in poezio, I came across a few points that make me shiver like chalk on blackboard each time I read them. All 3 points are in https://xmpp.org/extensions/xep-0384.html#usecases-messagesend. > When an OMEMO element is received, the client MUST check whether there > is a element with an rid attribute matching its own device ID. > If this is not the case, the element MUST be silently discarded. > If the element's contents are a SignalMessage, and the client has a > session with the sender's device, it tries to decrypt the > SignalMessage using this session. If the decryption fails or if the > element's contents are not a SignalMessage either, the OMEMO element > MUST be silently discarded. > If the OMEMO element contains a , it is an OMEMO message > element. The client tries to decrypt the base64 encoded contents using > the key and the authentication tag extracted from the element. > If the decryption fails, the client MUST silently discard the OMEMO > message. Can anybody explain why as a library dev I would want to silently discard messages and not let the end-users know they just lost messages? So that they can then take appropriate actions, (e.g., ask the other party to resend, file a bug in the library). I understand that in these cases the library is not able to decrypt these messages. My point is to let users know. Is there a reason I should respect these MUST? What happens if I don't? Is there any security/privacy implications? I would love to see a rationale added alongside if it is the case. Cheers, -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
