[Security] e2e requirements
ian.paterson at clientside.co.uk
Sat Mar 24 11:53:18 CDT 2007
> 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).
More information about the Security