[Standards-JIG] RE: Encrypted sessions
stpeter at jabber.org
Thu Jun 15 20:22:57 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
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"
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
> 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.
Jabber Software Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards