[Security] e2e requirements

[Ian Paterson]

Mridul wrote:
> 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.

SAS and/or Retained Secrets.

> 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 ?

You don't use public keys, or any other persistent ID. You use SAS 
and/or Retained Secrets instead of private key signatures.

> 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.

You seem to have understood correctly. The crypto world has been 
reexaming the old security "requirements" we are used to.

Also IM is different because it's about chatting - not about files, 
documents or mail. In real life almost all one-to-one chats are 
repudiable (deniable). Non-repudiation is useful for legal contracts and 
for court testimonies etc... but most of the time it is not desirable if 
you want people to feel they can chat *openly and freely*. IMHO the 
availability of open and free communication is essential to working 
things out between people, and to the health of relationships and of 
society in general. (See the OTR document for a more in-depth discussion.)

If there is demand for non-repudiation (e.g., to allow lawyers to send 
contracts inside IM chat messages instead of signed files) then it could 
be offered by a trivial extension to the e2e protocol (defined in an 
optional new XEP), or via an independent "stanza signing" protocol.

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

Upgradability doesn't affect stored/archived data, which is encrypted 
with an independent protocol (see XEP-0136).

FYI, the protocols are independent because they have very different 
security requirements (session vs object encryption).

> 5) Offline Sessions
> Not sure how we can support this if repudiability and perfect forward 
> secrecy are requirements. What about upgradability ?

XEP-0187 supports all these features with offline sessions. Obviously 
the Perfect Forward Secrecy window of vulnerability is longer when the 
receiver is offline... but it is likely to be a matter of hours not years.

FYI, XEP-0187 does not support full Identity Protection.

> Also, from what I see, otr, xtls, etc cannot satisfy this.

Well, I think we agreed not to go down the OTR path in the meeting, and 
OTR was designed to be compatible with proprietary IM protocols, some of 
which don't support offline messages.

I'm sure several of our requirements can't be satisfied by TLS over 
XMPP. After all it wasn't designed for IM, it was created by Netscape to 
download Web pages securely.

It may be that we can extend TLS to support those IM requirements. 
However, that will take some time, since in some cases designing the 
extensions will prove non-trivial (or perhaps even impossible?). In any 
case they probably won't be supported by OpenSSL or any other 
established library anytime soon (2008 at the earliest). I don't think 
it is worth waiting when we have other solutions.

I think we need to debate the desirability of those requirements which 
are not trivial to add to TLS. I'll come up with a list of those after 
Wednesday's council meeting (when we expect to split the Requirements 
into a separate XEP).

If we decide that those Requirements are important then we can stop 
considering TLS and people can concentrate on implementing ESessions. If 
not the debate may drag on.

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

Well, not if a whole ESession is replayed. I guess I just felt that 
replay protection was important enough to separate it from Integrity.

> 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.

It seems you've got the right idea. Although there are no 
interoperability issues, so maybe I just don't understand what you are 
saying? All PFS protocols do auth, so the territory is well covered. The 
answers you need are in the documentation (check out SIGMA or ZRTP or 
XEP-0188, RFC 4346).

- Ian