* Sergei Golovan <sgolo...@nes.ru> [2016-01-08 10:49]: > I don't think any API can tell you in advance that the encrypted message is > signed inside. Though, probably exposing this information isn't a good idea, > and you're right about the generic <openpgp/> element as a container.
I think that exposing this information is beneficial to the client, as it allows to better handle error cases (and indicate them to the user). I don't think there is a huge data leak beyond what is already seen in any case (sender, receiver, use of OX, in most cases also message type and key-ids from the OpenPGP packet metadata). Personally, I'd go one bold step further and remove all redundancy from the schema, as redundancy leads to inconsistency, and inconsistency leads to hard-to-find security issues. We've had those with NUL bytes in certificate CNs, UTF-8-based directory traversals, and many more. Therefore I propose the following (controversial) changes: 1. Completely get rid of <signcrypt/>, <sign/>, and <crypt/>. Store the children directly in the OX message body, or use a generic child element like e.g. <openpgpcontent/> Use (or create/adapt) the OpenPGP APIs in a fashion that allows to derive the sign/crypt flags and timestamp directly from the OpenPGP message. As it stands now, we are codifying workarounds to implementation shortcomings into the protocol. 2. Get rid of <time/> for the same reasons as #1. With the current state, an OX message can have up to three timestamps (XEP-203, OpenPGP metadata and <time/>). Which one should the client display? Which one is the authoritative? OTHER REMARKS 1. 'to' Element: Initially I was going to suggest also removing the 'to' element, as it is kind-of-duplicate to the key-id(s) stored in the OpenPGP metadata. However, as it seems to solve the Surreptitious Forwarding issue of OpenPGP, it probably needs to stay. §3.2 should be extended however, to clearly state that only the BARE JID needs to be checked. Furthermore, the rules for handling MUC/MIX need to be specified. Should the MUC/MIX JID be stored in the 'to' field, or a list of all participants for whom this message is encrypted? Should the MUC/MIX JID be allowed as a 'to' element when verifying an incoming message? If the individual user JIDs are used, how is a recipient going to distinguish a private message created for multiple people from a MUC/MIX message? 2. 'from' Element: I like symmetry, and where there's a 'to' there should be a 'from'. Of course this is the opposite of the "remove redundancy" idea further above, and so I would like to see a strong discussion/rationale about this. I'm not sure yet if "no redundancy" or "symmetry" is the better approach here. 3. Replay Attacks: §8.3 claims that Replay Attacks are prevented, without providing actual details. A combination of to+timestamp does not actually solve this problem, unless the receiver checks for timestamp increment/change (also think of out-of-order-delivery). Furthermore, the timestamp only is guaranteed to have 1-second granularity, so people will probably run into false replay suppression situations, unless we require the timestamp to be higher-precision or to be force-incremented for new (identical) messages. To properly protect against replays, an auto-incremented sequence number appears more practical. 4. 'rpad' Definition: The 'rpad' element is awfully underspecced: "The <signcrypt/> and <crypt/> elements SHOULD furthermore contain a 'rpad' element which text content is a random-length random-content padding." As this is a SHOULD, some authors will just ignore the requirement altogether, or cheat by using a fixed length or fixed content. My understanding is that OpenPGP automatically compresses the message before signing/encrypting, so cheating at the above will probably aid attackers. Nevertheless, I would like to see some strong suggestions for how to implement this. Is there really a benefit from having 'rpad' against traffic analysis, when also having c2s TLS? When should the 'rpad' element be really used (think of traffic cost on mobile)? Should the length of the padding depend on the content length (i.e. 0-20% of the actual content)? Which distribution should the lengths follow (normal, Poisson, ...)? 5. Public Key Discovery outside of XMPP (key UIDs): OpenPGP keys have one or multiple UIDs, that are a freeform text[0], usually containing a name + email address according to RFC2822. I propose using a more-strictly defined scheme for (auto-generated) OX keys, e.g. "User name <xmpp:jul...@example.org>" While this clashes with an email syntax from the pre-Internet days, it would allow using external infrastructure (PGP keyservers), as well as sharing one key between e-mail and XMPP without address conflicts[1], as well as getting the key signed by other people. Furthermore, it plugs the under-used RFC 5122. Georg [0] http://tools.ietf.org/html/rfc4880#section-5.11 [1] I am aware that this can have other drawbacks, my personal key is 126KB (in binary encoding). -- || 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: Digital signature
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
