[Security] e2e requirements

[Peter Saint-Andre]

In XEP-0188 and earlier XEP-0116, Ian Paterson and I defined a set of requirements for end-to-end encryption of XMPP stanzas. I'll repeat them (with sequential numbers) here so that we can discuss them and hopefully gain consensus. These requirements refer to the concept of an "ESession" (encrypted session) but should be generalizable to any technology that we choose to adopt.

******

1. Confidentiality



2. Integrity



3. Perfect Forward Secrecy



4. Replay Protection



5. PKI Independence



6. Authentication



7. Identity Protection



8. Repudiability



9. Robustness



10. Upgradability



11. Generality



12. Implementability



13. Usability



14. Efficiency



15. Flexibility



16. Interoperability



17. Offline Sessions



18. Object Encryption



******

The one-to-one XML stanzas exchanged between two entities MUST NOT be understandable to any other entity that might intercept the communications. Alice and Bob MUST be sure that no other entity may change the content of the XML stanzas they exchange, or remove or insert stanzas into the ESession undetected. The encrypted communication MUST NOT be revealed even if long-lived keys are compromised in the future (e.g., Steve steals Bob's computer). Alice or Bob MUST be able to identify and reject any communications that are copies of their previous communications resent by another entity. The protocol must not rely on any public key infrastructure (PKI), certification authority, web of trust, or any other trust model that is external to the trust established between Alice and Bob. However, if external authentication or trust models are available then Alice and Bob must be able to use them to enhance any trust that exists between them. Each party to a conversation MUST know that the other party is who they want to communicate with (Alice must be able to know that Bob really is Bob, and vice versa). No other entity should be able to identify Alice or Bob. The JIDs they use to route their stanzas are unavoidably vulnerable to interception. However, the public keys they use SHOULD NOT be revealed to other entities using a passive attack. Bob SHOULD also be able to choose between protecting either his public key or Alice's public key from disclosure through active ("man-in-the-middle") attacks. Alice and Bob MUST be able to repudiate any stanza that occurs within an ESession. After an ESession has finished, it SHOULD NOT be possible to prove cryptographically that any transcript has not been modified by a third party. The protocol must provide more than one difficult challenge that must be overcome before an attack can succeed (for example, by generating encryption keys using as many shared secrets as possible - like retained secrets or optional passwords). The protocol must be upgradable so that, if a vulnerability is discovered, a new version can fix it. Alice MUST tell Bob which versions of the protocol she is prepared to support. Then Bob MUST either choose one or reject the ESession. The solution should be generally applicable to the full content of any XML stanza type (<message/>, <presence/>, <iq/>) sent between two entities. It is deemed acceptable for now if the solution does not apply to many-to-many stanzas (e.g., groupchat messages sent within the context of multi-user chat) or one-to-many stanzas (e.g., presence "broadcasts" and pubsub notifications); end-to-end encryption of such stanzas may require separate solutions or extensions to the one-to-one session solution. The only good security technology is an implemented security technology. The solution should be one that typical client developers can implement in a relatively straightforward and interoperable fashion. The requirement of usability takes implementability one step further by stipulating that the solution must be one that organizations may deploy and humans may use with 100% transparency (with the ease-of-use of https:). Experience has shown that: solutions requiring a full public key infrastructure do not get widely deployed, and solutions requiring any user action are not widely used. If the users are prepared to verify the integrity of their copies of each other's keys then the necessary actions should be limited to a one-time out-of-band verification of a string of up to 6 alphanumeric characters. Cryptographic operations are highly CPU intensive, particularly public key and Diffie-Hellman operations. Cryptographic data structures can be relatively large especially public keys and certificates. The solution should perform efficiently even when CPU and network bandwidth are constrained. The number of stanzas required for ESession negotiation should be minimized. The solution should be compatible with existing (and future) cryptographic algorithms and identity certification schemes (including X.509 and PGP). The protocol should also be able to evolve to correct the weaknesses that are inevitably discovered once any cryptographic protocol is in widespread use. Ideally, it would be possible for an XMPP user to exchange encrypted messages (and, potentially, presence information) with users of non-XMPP messaging systems. Ideally, it should be possible to encrypt one-to-one communications that are stored for later delivery instead of being delivered immediately, such as so-called "offline messages". However, any vulnerabilities introduced to enable offline communications must not make online communications more vulnerable. For cases where a session is not desired, it should be possible to encrypt, sign and send a single stanza in isolation, so-called "object encryption".

smime.p7s
Description: S/MIME Cryptographic Signature