[Standards-JIG] The Great Encryption Debate
ian.paterson at clientside.co.uk
Fri Aug 12 16:21:24 UTC 2005
> Ian Paterson points out that JEP-0116 wouldn't look so complex if we
> had a library people could embed in their applications, as they do now
> for things like SSL and PGP. But then we have interoperability through
> monopoly as opposed to interoperability through transparency.
I think there may have been a misunderstanding. I never said anything
like, "JEP-0116 is complex and difficult to follow, but as long as we
only have one implementation then it will be interoperable". I did say:
"the reason JEP-0027 and RFC 3923 *seem* more simple is because they are
built on top of high level protocols".
JEP-0116 includes all the necessary lower-level specifications that are
hidden away from readers of JEP-0027 and RFC 3923 (in the PGP and S/MIME
documents). If, for a second, we imagine implementations of PGP and
S/MIME do not exist then, IMHO, JEP-0116 is far easier to implement than
either of the roughly equivalent combinations of JEP-0027 and PGP, or
RFC 3923 and S/MIME.
Of course implementations of PGP and S/MIME do exist, but unfortunately,
those protocols are poorly adapted to the needs of IM. Once we've
decided that we can't build on top of existing protocols, then we have
to accept that our protocol JEP will be a little more complex.
PGP started out with a single implementation. The new IM-friendly
protocol we decide on will also have to start with one. Today many
client developers might not feel comfortable implementing a lower-level
protocol. But, once we have the first (of many) libraries, then
supporting encryption will be more simple than ever before.
Happily one protocol dedicated to IM does exist. IMHO "OTR" is a good
protocol. We can't build on it directly because it is not XML-friendly.
But JEP-0116 emulates it, and OTR's existing LGPL library should give
JEP-0116 developers a big head start.
Of course I would like JEP-0116 to be as simple as possible. Perhaps we
should also write a synopsis JEP (at the level of JEP-0027 for
developers using a library), and even (eventually) move "Offline
Esessions" into another JEP?
> I also continue to think that online communications are
> more important than offline communications, although I
> don't have objections to developing something like the
> offline DH exchange that Ian outlines in JEP-0116
Clearly online is more important for IM and that is why we want
Esessions. But I often use XMPP's offline delivery feature to send a few
separate sentences to someone who I know is offline (instead of sending
them an email). I *really* don't want to have to worry that if I send an
XMPP message offline then it won't be encrypted. It would also be
difficult to explain this security 'loophole' to Aunt Tillie.
> In general, I think it would be best to develop e2e security
> solutions that leverage what is distinctive about IM
> applications (especially XMPP):
> 1. rosters
> 2. presence
> 3. sessions
Yes. And I'd add: 4. existing server-network
More information about the Standards