[Standards-JIG] RE: Encrypted sessions
jean-louis.seguineau at laposte.net
Thu Jun 8 13:11:28 UTC 2006
Ian, I do not agree with what you said about PFS. You are perfectly right
that un-encrypted offline data is less secure than encrypted data ;) I am
certainly NOT going to argue about this. I believe it is worth splitting the
JEP and handling the "offline encrypted" data separately. I explain my
For PFS to exist the key used to protect transmission of data must not be
used to derive any additional keys. When "offline data" are encrypted the
offline party must be able to recreate the crypto material from its current
long term key and additional parameters. During the period in which the
party is offline, the probability for the long term key and state to be
compromised is greater than if there is no long term key nor waiting
information stored on the server. The JEP section 8.2.1 says
"Alice MUST store her value of NA (her ESession ID) and all her values of x
(one for each MODP group) in a secure way, so that she can retrieve them
when she comes back online (ideally even if that is using a different client
and/or a different machine)"
This statement mandates sensitive information to be stored on Alice's
workstation, or worth, on an intermediate storage (XMPP server?). By
acquiring this information an attacker can 1/ reconstruct the crypto
material used to encrypt the "offline" data, 2/ impersonate Alice for
further sessions as the attacker as gained access to the private DH keys.
There are two weak points in the chain 1/ Alice's workstation, 2/ Alice's
server where the "offline" storage also stores information on how to decrypt
the offline data.
But this decreased security level is NOT induced by the JEP itself. Whenever
keys have to be stored, there is a greater key compromising probability. It
is IMHO neither worst nor better than the PKI requirement to store private
keys. On the contrary, when there is NO need to store keys, the overall
security level increases.
Coming back to securing "offline" data, what I just said does not address
the issue. But from a security perspective, it is more secure NOT to store
encrypted "offline" data than to store it. Beyond this argument, we may want
1/ assert the actual need for encrypted "offline" data and examine
alternative communication means.
2/ determine if the method proposed in the JEP is acceptable, or if a
different approach leads to better/easier implementation.
3/ examine the possibility to split the JEP in two parts, one dealing with
"online" communications, the other dealing with "offline" data.
The JEP is great at wrapping SIGMA for the key exchange, leveraging
experience from IKE and IPSec. The JEP does a good job at using the
"off-the-record" approach. But these bases have been designed for securing
live conversations, NOT persisting data in the first place.
When dealing with security, the safest attitude is to decrease the risk
whenever possible. Storing keys introduce a greater risk than using
completely volatile keys. It also introduces a greater level of complexity
in the implementation.
Date: Thu, 8 Jun 2006 04:18:01 +0100
From: "Ian Paterson" <ian.paterson at clientside.co.uk>
Subject: RE: [Standards-JIG] RE: Encrypted sessions
To: "'Jabber protocol discussion list'" <standards-jig at jabber.org>
Message-ID: <003601c68aaa$26de15c0$0300000a at dell8500>
Keywords: News, Ideas
Content-Type: text/plain; charset="us-ascii"
> The JEP-116 without "offline encryption"
> will be even more secure, because there won't be any inter
> session key material left to be compromised. This is what
> real Perfect Forward Secrecy is about.
Since the alternative is no encryption of offline messages, it could
hardly be "even more secure". ;-)
Offline messages would still benefit from Perfect Forward Secrecy,
although PFS would not start until the user came online.
> The added complexity comes in the management of crypto material
> sessions (check, remove, add, etc...) just for the sake of
> "offline encryption". Without this part, JEP-116
> implementation is straightforward. Is the added complexity
> worth the effort?
IMHO yes, absolutely (see above).
Note that offline encryption is already optional (MAY), so implementors
can decide for themselves.
If it makes it easier for implementors I suppose we could consider
spliting the document into two JEPs?
After all, online-only encryption is better than no encryption at all.
More information about the Standards