* Jonas Schäfer <[email protected]> [2019-06-19 17:00]: > Title: Stanza Content Encryption
This was long overdue. Some ideas for consideration: 1. I'd like to see certain fields of the <content/> being REQUIRED, especially: - the from address - maybe, possibly, the recipient address(es) - a <time> (or <delay>) element - the @id / origin-id The @id can be used for deduplication of the content, from/to can be used to check whether an encrypted message was forwarded by an attacker and the <delay> element ensures that replay attacks become visible. 2. In an encryption protocol idea that I briefly entertained, I was pondering about actually embedding a regular XMPP <message> stanza inside the encrypted container, with the from and to addresses being bare JIDs of the respective parties. This _might_ make the XML parsing / stanza reinjection part of things more straight-forward, but I'm not going to die on this hill. 3. From §9: > After verifying the integrity of the <content/> element, the recipient > needs to make sure that no blacklisted elements are found within the > payload. Any forbidden elements MUST be dropped before the message is > processed any further. I would prefer aborting the processing altogether instead of dropping individual elements. In the context of security, a protocol is more robust if it properly rejects unexpected border cases. Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
