[Standards-JIG] RE: Encrypted sessions

Peter Saint-Andre stpeter at jabber.org
Thu Jun 15 20:22:57 UTC 2006

Hash: SHA1

Ian Paterson wrote:

>> 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"
> section.

Yes, good point. In general we probably need to look at a range of
potential downgrade attacks from encrypted sessions to offline messages.

>> 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.

True. Since keys are cheap, there's no reason not to re-generate them
whenever needed.

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

Oops, sorry, I spaced this out. We'll discuss it in the meeting on June
27. But since it's really just a split of existing content into multiple
documents, I don't think Council approval is aboslutely necessary (but
in the past I've done that since the Council is the body that needs to
approve of publishing all initial JEPs and I like to follow processes
we've defined :-).

That said, I'm not fully convinced that we need to create separate JEPs,
in general I've received feedback from implementors that it's harder to
keep track of things that way.


- --
Peter Saint-Andre
Jabber Software Foundation

Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060615/c97a6fc3/attachment.bin>

More information about the Standards mailing list