Justin Karneges wrote:
On Tuesday 09 January 2007 11:33 am, Peter Saint-Andre wrote:It's time for us to get serious about end-to-end encryption (e2e).Ian Paterson has been working hard on specs for e2e. I think we now have the pieces in place for strong e2e between any two users, in a way that even Aunt Tillie can use. Now we need to make it happen.I read through the XEPs, and my initial reaction is ... holy smokes this is a lot of material! And we're worried programmers will have trouble parsing CPIM? :)I think the e2e XEPs may be great in the long term, but it will be years before this is implemented widespread.
So let's get to work, then. :-)
First, we need thorough security reviews of all the specifications by multiple parties.
All the existing specs (RFCs/MUC/etc.) or the esession specs?Security reviews of all the existing specs is a good idea, but that doesn't solve the e2e problem.
Then we can implement, and that will take time too.
Right. Which is why it's time to get busy.
Just to bring reality home here.. show of hands for developers even doing certificate validation with TLS?Also, Ian also has a tendency to incorporate bleeding edge security algorithms and procedures, that I'm not sure have received proper scrutiny..
The SHA family is broken. It's only a matter of time before SHA-256 and even SHA-512 are cracked (but those at least are a damn sight better than SHA-1). In any case these are negotiation options and we need to remain flexible with regard to algorithms as old ones are comprimised.
The main thing I'd like to see are some security reviews by people who actually design and implement crypto. Let's hear from Peter Guttman or Eric Rescorla. We need prominent members in the security community that not only will do a basic error check, but will also ask important questions like, "why the hell are you doing it this way?" :)
See Step 1 in my previous email. A full security review of the esession specs by a prominent member of the security mafia is going to be part of this.
I'll be implementing RFC 3923 until then.
Yes, and I see that you sign your email with a digital certificate using S/MIME. :-) IMHO RFC 3923 is simply not a go-forward technology because of the dependency on end-user PKI (hell, even very few members of the security mafia use S/MIME). The lack of a CPIM parser is the least of the problems with RFC 3923.
Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
