[Standards-JIG] The Great Encryption Debate
justin-keyword-jabber.093179 at affinix.com
Tue Aug 2 21:27:34 UTC 2005
On Tuesday 02 August 2005 11:10 am, Peter Saint-Andre wrote:
> So I propose that we initiate "The Great Encryption Debate". Any and all
> proposals are on the table. Let's publish Justin's "Secure Stanzas"
> proposal. Let's publish a proposal based on W3C XML Encryption and XML
> Signature  if someone wants to write such a proposal. Let's debate
> the merits of RFC 3923 and JEP-0027. Let's talk about the Off-the-Record
> Communications (OTR) plugin for Gaim.  Let's discuss JEP-0116. 
> But let's not just talk, let's also implement. (I apologize in advance
> for the fact that I'm not a good coder, but I'll try to help if I can.)
JEP-0116 looks good. At first glance:
1) nit: section 9.1 and 9.3 have the same title
2) section 9.5 makes no mention of MAC algorithms
3) section 9.5.3 mentions ssh-rsa/ssh-dss formats. I'd prefer the
more-standard X.509 plain public key formats (not to be confused with
certificates! I'm talking about "BEGIN PUBLIC KEY").
1) xmlenc. The <encrypted> element from this JEP is doing almost the same
thing. If xmlenc is to be avoided, maybe the authors should share their
2) offline diffie-hellman. This process is interesting, especially the bit
about disco-publish. Could it really supplant a single-stanza security
protocol for offline usage? What considerations are there regarding
timestamping and replay attacks?
3) presence signing. JEP-0116 does not cover this topic. What do others
think about it? This might be something that only object security can
4) groupchat. I disagree with section 4.2.1. I think we should find a way
to secure groupchat right away, especially with something session-based.
5) public key transport. We really should move this to a separate JEP, I
think we'll be able to think more clearly, especially since it is part of the
session vs. object security overlap.
On complexity and single stanza security:
One big issue I see is JEP-0116's complexity. There is a lot of room for
error here, fooling around with individual algorithms. It may be that this
is the only way to get good session security. With that in mind though, I
think RFC 3923's complexity is greatly exaggerated. Creating an S/MIME
payload with OpenSSL is just a few lines of code. The difficult part is the
handling of the X.509 structures, which you'd have to do with JEP-0116
anyway. With regards to section 4.2.2, I see developers having an easier
time with CPIM+S/MIME than with this JEP.
RFC 3923 goes beyond JEP-0027 by providing security for all stanza types,
X.509 capability, and public key transport, at the cost of losing PGP
capability. My "jep-secure" provides the same things as RFC 3923 (although
via reinvention rather than a delta), with the addition of PGP and an
anti-replay attack mechanism. I'm considering turning jep-secure into an
extension for RFC 3923, rather than a competitor. What do others think about
More information about the Standards