[Standards-JIG] JEP-0136: Message Archiving

Michael Long Michael.Long at cornerstone.net
Tue Jan 17 16:38:00 UTC 2006


Per Ian's request, I am informing the mailing list of the correspondence between Ian Paterson and myself regarding JEP-0136: Message Archiving.

What follows is a series of emails exchanged between Ian Paterson and myself between 05-Jan-06 and 06-Jan-06.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
========================================================================
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

From: Michael J. Long <Michael.Long at cornerstone.net>
To: justin at affinix.com, Ian Paterson <ian.paterson at clientside.co.uk>
Subject: Q: JEP-0136: Message Archiving
Sent: Thu 05-Jan-06 10:36 AM

I have recently come across the specification you have written, JEP-0136: Message Archiving, and would like to ask a few questions.

I have scanned the specification and noticed that it allows the client to completely control the message archive, including creating and adding messages to that archive. I also noticed that the specification indicates "server autoarchiving approach would have eliminated the need to submit collections to the server". Does the specification not address autoarchiving because it is covered in another specification or because you wanted to allow the client to completely control the message archive?

If autoarchiving is not covered in another specification, would it be possible to extend your specification to allow for autoarchiving? I have several ideas in this area, from allowing the client to start/stop message archival for a particular conversation to allowing the user to indicate a preference to always autoarchive all conversations. I would be open to discussing and hashing out these ideas and others related to server autoarchiving of messages.

My interest in this is that I am working on a project that needs to use some sort of server-side message archive storage and retreival. We would prefer to follow a standard (even an experimental one) rather than developing our own, non-standard implementation.

I look forward to your response.

--
Michael J. Long

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
========================================================================
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

From: Ian Paterson <ian.paterson at clientside.co.uk>
To: Michael J. Long <Michael.Long at cornerstone.net>
Subject: RE: JEP-0136: Message Archiving
Sent: Thu 05-Jan-06 1:31 PM

Hi Michael,

Thanks for your interest and suggestions for JEP-0136.

>  Does the specification not address autoarchiving because it
> is covered in another specification or because you wanted to
> allow the client to completely control the message archive?

JEP-0136 enables client-controlled autoarchiving because:

1. "The specification empowers clients, enabling them to store
out-of-band messages like email as well."

JEP-0136 avoids server-controlled autoarchiving because:

2. "End-to-end encryption schemes typically use evanescent keys that are
discarded immediately after use, server autoarchived encrypted messages
would not be decryptable."
3. (not yet mentioned in the spec) An evil server admin or attacker
would have access to all previous conversations, not just current
conversations (if conversations are encrypted by the client with a
secret that is unknown to the server this threat goes away).


> If autoarchiving is not covered in another specification,
> would it be possible to extend your specification to allow
> for autoarchiving?

It would be simple to extend the spec as you suggest. However, the
people I have discussed this spec with up to now have tended to agree
that personal IM privacy (points 2 and 3 above) is so important that we
shouldn't encourage server-side autoarchiving by including it in JEPs.

> My interest in this is that I am working on a project that
> needs to use some sort of server-side message archive storage
> and retreival.

Yes, and I guess you won't be the last - since large organisations often
have to comply with "full disclosure" legislation. The existing spec
does make plaintext archival possible under the direct control of the
client. Can I assume you've considered that option?

Can you think of a way other than server-side archiving that would
address the privacy concerns and your concerns?

For my interest only, if server-side autoarchiving became an optional
(MAY) part of JEP-0136, and client-controlled archiving was compulsory
(MUST) would your project most likely implement both (on client and
server), or only the server controled storage?

If the spec were extended to include server-controlled archiving then I
agree with you that allowing the client to start/stop message
autoarchival (either globally, or for an individual JID or roster group)
would be important.

I think this conversation is of general interest, do you have any
objections to continuing it on the Standards-JIG mailing list?

I look forward to hearing from you. :-)

Cheers,

- Ian

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
========================================================================
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

From: Michael J. Long <Michael.Long at cornerstone.net>
To: Ian Paterson <ian.paterson at clientside.co.uk>
CC: justin at affinix.com
Subject: RE: JEP-0136: Message Archiving
Sent: Fri 06-Jan-06 11:14 AM

Ian Paterson wrote:
> Michael J. Long wrote:
>
> JEP-0136 avoids server-controlled autoarchiving because:
>
> 2. "End-to-end encryption schemes typically use evanescent keys that are
> discarded immediately after use, server autoarchived encrypted messages
> would not be decryptable."

Using the start/stop method I mentioned should allow for this. When sending a start message, we send the key (encrypted by the client, of course) that can be used to decrypt it. Therefore, the server can autoarchive the encrypted messages (without decrypting them) and the client will be able to decrypt the retreived archive.

A major drawback of the server autoarchiving would be that the same key would be used to decrypt the messages (by the client) in real-time and in the archive. This could be considered a security issue.

> 3. (not yet mentioned in the spec) An evil server admin or attacker
> would have access to all previous conversations, not just current
> conversations (if conversations are encrypted by the client with a
> secret that is unknown to the server this threat goes away).

What if the client sent the server (in the start message) a key used to encrypt the messages for the archive? For maximum security, the client should send a public key of a public/private key pair. Or, in the case where the user wants the server to always autoarchive, configure the user's settings with the public key. Of course, for conversations described by item 2 (you introduced, above), the client would have to send the conversation decryption key at some time during the conversation so the archive can be decrypted later.

If any (or all) of the above doesn't make any sense, I apologize. I have a (very) limited knowledge of security mechanisms.

>> would it be possible to extend your specification to allow
>> for autoarchiving?
>
> It would be simple to extend the spec as you suggest. However, the
> people I have discussed this spec with up to now have tended to agree
> that personal IM privacy (points 2 and 3 above) is so important that we
> shouldn't encourage server-side autoarchiving by including it in JEPs.

And I also agree that privacy is of the utmost importance for most systems. However, I believe that both aspects (server autoarchiving and privacy) can be addressed.

>> My interest in this is that I am working on a project that
>> needs to use some sort of server-side message archive storage
>> and retreival.
>
> Yes, and I guess you won't be the last - since large organisations often
> have to comply with "full disclosure" legislation. The existing spec
> does make plaintext archival possible under the direct control of the
> client. Can I assume you've considered that option?

Yes, I have considered that option but that would involve a considerable amount of work on the client (FYI, a limited-functionality web client integrated with a web application in a closed environment). As every message passes through the server, we thought that server archiving would be an optimal solution. As I described before, we could create a custom mechanism to reach our goals but we would prefer to follow a standard (and possibly contribute back to the community that has helped us so much already).

We don't intend for this client to be released back to the community, as it is a very limited implementation. But we would like to contribute the server-side implementation we develop (probably a plugin for Wildfire server, aka Jive Messenger) back to the community. We would prefer to put more effort into the server than the client. If the server could autoarchive, then the client would just have to retreive and display the archive, not maintain it.

> Can you think of a way other than server-side archiving that would
> address the privacy concerns and your concerns?

As we are not as concerned with privacy on the server, I have not thought through (in great detail) our solution as it relates to privacy. We have other mechanisms in place to prevent unauthorized access to the message archive. However, as I described above, I can envision a mechanism to allow for autoarchiving that still honors privacy.

> For my interest only, if server-side autoarchiving became an optional
> (MAY) part of JEP-0136, and client-controlled archiving was compulsory
> (MUST) would your project most likely implement both (on client and
> server), or only the server controled storage?

As I described earlier, we are more interested in the server-side of things. And, that is probably what we would implement first. However, we are also interested in contributing back to the community, therefore, we will likely implement (on the server) the full specification before releasing it to the public. As we would need to test our server-side implementation in some way, we would probably have to fully implement the specification on a client. At this point, I am unsure of which client that may be. Any suggestions? :-)

> I think this conversation is of general interest, do you have any
> objections to continuing it on the Standards-JIG mailing list?

No objections. Would you like me to copy our correspondence to the list? I was not aware of that mailing list before now (I found the JEP via a web search and have not had any interest in modifying any other specifications). Now that you have opened my eyes, I will be sure to read any reference to JEP-0136 and see how ignorant I am.


--
Michael J. Long

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
========================================================================
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

-- 
Michael J. Long

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060117/33839d14/attachment.html>


More information about the Standards mailing list