[Standards-JIG] UPDATED: JEP-0136 (Message Archiving)
ian.paterson at clientside.co.uk
Sun Sep 10 03:13:15 UTC 2006
Hi Olivier, thanks for your feedback:
> I want the automatic archiving be working on every client, and the client must
> not require to do anything.
> (one rules one teach me is : put the complexity on the server, not the client)
> So there are two issues:
> - The client shouldn't need to send the <auto/> to enable automatic archiving
"Simple client complex server" is important. But IMHO ensuring that
users can control their own privacy is much more important.
Anyway, simple client isn't really an issue here, because it is
absolutely trivial for clients to switch on auto-archiving (just send
If the user's client doesn't know how to switch auto-archiving on, then
it certainly doesn't know how to retrieve the messages!
> - The usage JEP-0155 is basically a client-to-client protocol which will not
> work well for OTR in automatic archiving.
Did something make you change your mind since your previous post?:
Olivier wrote on Aug 22:
> > If you don't want to be recorded, ask your contact to
> > disable himself recording. As simple as that, no need to
> > add useless and complex protocol to do that. (useless
> > because I work around it)
I agree with that earlier opinion of yours. You can't achieve OTR
without JEP-0155 (or something else that does the same thing). Even if
you implement OTR on the server, you've still got to ask your contact
not to log messages in any of the numerous other ways that are possible.
So you always need JEP-0155. So the question becomes: "What is the point
in having server OTR if you've already got JEP-0155?" IMHO it just adds
unnecessary complexity to both client and server.
> I have also some issues regarding the encryption :
> - Would it be fine if the user just specify a passphrase to access the
> history, and all encryption and decryption mechanism are done into the
> server ? (simple client/complex server)
With manual archiving the idea is you don't trust your server (the
messages hopefully arrived through an end-2-end encrypted session). So
the client should perform both encryption and decryption.
With auto-archiving things aren't so clear. JEP-0136 currently specifies
that the server should perform the encryption but not the decryption. If
we can assume that all client-server streams will be secure, then I
guess the server could perform the decryption too. It would be easy for
the client to generate a different password (on server demand) for each
message collection (e.g., by hashing a randomly generated public
collection label together with the password supplied by the user).
But the risk is still increased, because each time messages are
decrypted the client would have to trust that its server hasn't been
compromised (not just whenever messages are encrypted). Also clients
will use the same software to decrypt all collections (whether manually
or auto archived). So, if manual archive decryption is supported, there
is no increase in client complexity.
"Simple client complex server" is important. But, IMHO, security is far
> - Else, how are the secrets keys shared between clients ?
That is beyond the scope of JEP-0136. But perhaps we could add a note?
Since the private keys are long-lived, they could be transported via
USB-key. Alternatively, they could be password encrypted and then stored
on the server using a to-be-defined standard protocol (on my list of
protocols to write in 2007).
More information about the Standards