[Security] e2e requirements
stpeter at jabber.org
Tue Mar 27 21:06:53 CDT 2007
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).
> 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.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20070327/dbab7eab/smime.bin
More information about the Security