Ian Paterson wrote:
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.)
Interestingly, when Jer and I worked on a "vision statement" for Jabber technologies back in 2000 or so, the core goal we described was "fostering freedom of conversation". There are many senses of freedom, and this is one of them.
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.
Stanza signing would be good for other reasons. But I don't think we'll see too much demand for non-repudiation.
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.
Sure, there is standards work to be done (e.g., a TLS extensions for SAS) and then those standards need to be implemented, so 2008 may be ambitious. I don't know how quickly the existing TLS extensions have been implemented, that would be a good data point to gather.
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).
Great.
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.
I agree that getting clear on the requirements is key. Then we can do a "gap analysis" to see how XTLS and ESessions address the requirements.
Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
