[Standards-JIG] RE: Encrypted sessions

Ian Paterson ian.paterson at clientside.co.uk
Thu Jun 8 23:15:29 UTC 2006

JEP-0116 provides PFS for offline messages in as much as that, as soon
as the recipient comes online, the messages will be decrypted and the
key required to decrypt them will be destroyed immediately. I used to
call this "Imperfect Forward Secrecy" until I was informed by a
respected crypto expert that, despite the delay in destruction of a few
hours, it is still PFS (since, once the recipient has read them, it is
impossible for anyone to decrypt the messages - even if he/she possesses
the recipient's long-term key).

Jean-Louis wrote:
> 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.

Yes. Some sort of key must be stored somewhere for *any* possible
offline encryption scheme. Offline communication is simply more
difficult to secure than online.

> an attacker can... 2/ impersonate Alice for further
> [offline] sessions

Very good point. :-) I've added this to the CVS copy of the JEP - in the
"Offline ESessions" sub-section of the "Security Considerations"

> It is IMHO neither worse nor better
> than the PKI requirement to store private keys.

IMHO JEP-0116's storage of offline Diffie-Hellman keys is much less
serious than storing PKI keys. Compromised PKI keys could be used by a
man-in-the-middle to decript and *encrypt* messages in future online
(bi-directional) Esessions. Whereas compromised offline DH keys could
only be used to decrypt offline (mono-directional) Esessions.

Offline ESessions *are* significantly less secure than online Esessions.
But with the JEP-0116 approach, the keys exist for the minimum possible
amount of time (I certainly wouldn't call them "long-term"). So JEP-0116
should be more secure than any scheme where secrecy relies on truly
long-term keys (years instead of hours) - e.g. encrypted email.

Peter wrote:
> 1. Wait until the person is online (presence rocks).

What if the message is urgent and we know we'll be offline by the time
the other person comes online (we're about to jump on a flight).

> 2. Send one offline message saying "ping me when you're online".
> Naturally, your client would need to pop up a big security 
> warning at this point with text like "ARE YOU SURE YOU WANT 
> and defaulting to "NO!"

Yes, but that is an unfriendly restriction. Since offline message
encryption is possible (and infinitely better than no encryption at
all), we should at least allow developers to provide it for the users.

More importantly, the answer to point 1 above also applies here.

> 3. Send encrypted email saying "let's set up a time to chat".

Switching to email is inconvenient for users. I can't believe you even
suggested that! ;-)

Jean-Louis wrote:
> 1/ assert the actual need for encrypted "offline" data and 
> examine alternative communication means.

See the answers to Peter's suggestions above. Encrypted "offline" data
is going to be necessary in some situations. 

"alternative communication means" will face the same challenges that
XMPP does (and they may not be either available or convenient). So IMHO
we have to tackle the offline encryption issue.

> 2/ determine if the method proposed in the JEP is acceptable,
> or if a different approach leads to better/easier implementation.

I'm certainly open to other approaches. (And that openness is another
good reason to separate Offline ESessions into a separate JEP.)

The motivation behind JEP-0116's solution was to reuse most of the
online-encryption code (easier implementation). JEP-0116 also offers PFS
(more secure than other proposals).

> 3/ examine 
> the possibility to split the JEP in two parts, one dealing with
> "online" communications, the other dealing with "offline" data.

Yes. Offline encryption is already optional. Two JEPs would make the
protocol(s) more approachable. Perhaps the "Requirements",
"Cryptographic Origins" and "Cryptographic Design" sections could also
be moved into a third document since they are targeted at protocol
designers not implementors (who may find them intimidating)?

Peter I'd like to get Council agreement before I undertake that task.
Can you please add it to the agenda of the next meeting. Thanks. :-)

- Ian

More information about the Standards mailing list