[Standards-JIG] The Great Encryption Debate

Justin Karneges 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 [4] 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. [5] Let's discuss JEP-0116. [6]
> 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").

Larger issues:

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

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

  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.

On "jep-secure":

  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 
this?

-Justin



More information about the Standards mailing list