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

[Ian Paterson]

Olivier Goffart wrote:
> Yes, but what if i use an old client which doesn't support the 
> feature at all ? Messages are then not logged -> data loss 
>   

Yes, but the situation will be vastly improved from today's, where tiny 
clients either don't or can't store data locally (e.g. Web/mobile 
clients). Tiny clients have the most to gain from this protocol, and 
sending <auto/> is trivial for any client... if your client doesn't 
implement <auto/> then it really should. So use a different client 
(there are a lot out there).

Your server can be expected to take much longer than your client to 
implement automatic-archiving.

IMHO there is no serious or long-term issue here, so privacy concerns 
should take precedent. [I remember these concerns aren't particularly 
important for you, but they are crucial for a lot of (oppressed) people 
who we have to respect.]

See below for another significant argument for auto-archiving always 
defaulting to 'off'.


Note that the protocol says "Automatic archiving SHOULD default to 
disabled" (not MUST). The reason for SHOULD is that the policy of an 
organization may require an administrator to change a server's default 
setting so that it logs all messages (in which case clients should not 
be able to disable auto-archiving).

So we probably need an extra protective clause in JEP-0155 (and 
JEP-0136) to say that a client MUST NOT agree to logging='false' unless 
it has confirmed that its server will allow it to switch off 
auto-archiving. JEP-0155 is still "Experimental" so we could even change 
the name of the 'logging' field to 'otr', so clients can be sure they 
are not dealing with a legacy implementation. What do you think Peter?

>> [...] 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.
>>     
>
> So the server is supposed to analyze JEP-0155 messages?

No. Perhaps something in the protocol has not been made clear to you? If 
the clients agree there will be no logging of any kind using the 
JEP-0155 'logging' field, then it is the responsability of each client 
to switch off *its own* auto-archiving and/or any of the other archiving 
methods they might be using. If you could tell me which part(s) of the 
JEP may have mislead you then I'll try to make things more clear for 
future readers.

> And if the other client doesn't support OTR (but his server does) ?
>   

If the other client doesn't support OTR then it is probably archiving 
locally in a completely different (proprietary) way. So you have no OTR. 
Unless both:

1) You use JEP-0155 to get the other client to agree to switch off its 
non-standard archiving (all archiving), and
2) Auto-archiving defaults to 'off' on the other client's server.

> Maybe could work if a <otr/> tag is added in 
> messages so the server knows it is otr.
>   
IMHO, this server analysis of every stanza is undesirable, and not at 
all helpful. (Since contacts that don't understand JEP-0136 will 
probably be archiving in some other way, in which case only JEP-0155 can 
help you.)

>> Since the private keys are long-lived, they 
>> could be transported via USB-key. 
>>     
>
> Not really user friendly.
> Or is encryption reserved to geek ?
>   

Yes, I agree, this is not a good solution. I only mentioned it because 
it should be more secure than the other solution:

>> 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).
>>     
>
> jabber:iq:private (JEP-0049)
>   
Could be, although we would still need a JEP to standardise the content 
of the <query/> element. Also jabber:iq:private is probably going to be 
depricated in favour of PEP (JEP-0163) so new protocols should avoid 
using JEP-0049.

This method becomes more secure if it is only used to transfer a private 
key in-band. i.e. ClientA encrypts the key with a password supplied by 
the user and stores it on the server, the next time ClientB comes online 
it retrieves the key and then immediately deletes the copy on the 
server. This way the period of vulnerability is significantly reduced. 
Unlike the USB-key transfer method, this process could be made 
transparent to users.

> The problem i see in the current implementation is that each client must have 
> the private key in order to encrypt. or to enable automatic archiving with 
> encryption
>
> The possible solution is to let the server aware of the public key, so it can 
> generate secret session keys himself.
>   

Very good point. I'll make that change to the protocol.

Thanks again for all your input (even the bits I disagreed with). :-)

- Ian