[Security] e2e requirements

[Mridul]

Hi,

   Just some comments about the requirements.
I am not as familiar with esessions as I would like to be, so it likely 
that I am missing something. But looking from point of xmpp requirements 
in general ...


1) pki independence and authentication.
Typically authentication/verification would require pki dependence.
Since auth is mentioned as a MUST, I am not sure how we can achieve both.

2) Identity Protection
Not sure about this ... encrypt with public key, receiver decrypts with 
private key : maybe I misunderstood the intent here ? Why should the 
public key used not be known to others ?

3) Description about repudiability
Just to get it clarified - the intent of the description is not to allow 
repudiation between participants while a session is in progress, but 
w.r.t others once a session is over right ? (ability to deny)
This feels like reverse of most security requirements I have seen, so 
want to get it clarified.

4) Upgradability
How does this affect stored/archived data ? (may not be relevant here ?)

5) Offline Sessions
Not sure how we can support this if repudiability and perfect forward 
secrecy are requirements. What about upgradability ?
Also, from what I see, otr, xtls, etc cannot satisfy this.


As already voiced in the conference, usability as a primary requirement 
is a bit tough to solve - without different solutions for different 
requirements (need for compliance vs otr for example : 136 does attempt 
try to combine both nicely btw).

Also, isn't replay protection not a subset of integrity here ?

One of the other things which is nagging me is - Perfect forward secrecy 
and authentication.
I can think of validation followed by generation of short term random 
key which gets used for the actual session encryption, etc: but not sure 
if that was the intent, and how interoperable such an approach would be.


Regards,
Mridul

Peter Saint-Andre wrote:
> 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
> 
> The one-to-one XML stanzas exchanged between two entities MUST NOT be 
> understandable to any other entity that might intercept the communications.
> 
> 2. Integrity
> 
> 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.
> 
> 3. Perfect Forward Secrecy
> 
> The encrypted communication MUST NOT be revealed even if long-lived keys 
> are compromised in the future (e.g., Steve steals Bob's computer).
> 
> 4. Replay Protection
> 
> Alice or Bob MUST be able to identify and reject any communications that 
> are copies of their previous communications resent by another entity.
> 
> 5. PKI Independence
> 
> 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.
> 
> 6. Authentication
> 
> 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).
> 
> 7. Identity Protection
> 
> 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.
> 
> 8. Repudiability
> 
> 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.
> 
> 9. Robustness
> 
> 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).
> 
> 10. Upgradability
> 
> 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.
> 
> 11. Generality
> 
> 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.
> 
> 12. Implementability
> 
> 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.
> 
> 13. Usability
> 
> 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.
> 
> 14. Efficiency
> 
> 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.
> 
> 15. Flexibility
> 
> 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.
> 
> 16. Interoperability
> 
> Ideally, it would be possible for an XMPP user to exchange encrypted 
> messages (and, potentially, presence information) with users of non-XMPP 
> messaging systems.
> 
> 17. Offline Sessions
> 
> 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.
> 
> 18. Object Encryption
> 
> 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".
> 
> ******
> 
>