[Standards-JIG] UPDATED: JEP-0136 (Message Archiving)

[Ian Paterson]

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 
<auto/>).

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 
more important.
>  - 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).

- Ian