Justin Karneges wrote:
On Tuesday 09 January 2007 12:24 pm, Peter Saint-Andre wrote:Justin Karneges wrote: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.e2e.RFC 3920 doesn't need the same scrutiny, because it uses the off-the-shelf TLS protocol. Problems in the RFC should stick out like a sore thumb to any security-conscious developer. No need to bring in the security mafia.
Right, we're mostly just re-using things there. And the RFCs have already gone through cross-area review anyway.
Esessions, on the other hand, is very low level, and this means a large opportunity for errors (both in design and implementation). Most of us are unqualified to review the esessions design, and so we definitely need experts to step in here and assist.
Right, that's why we need an independent security review.
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.Not just SHA, but also SIGMA.
SIGMA is more of a philosophy than an algorithm. It underlies things like IKE and other technologies that have undergone fairly thorough review.
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'd like to see at least 2 people review it, with at least one of them unsympathetic to XMPP.
We may have money to pay for only one review. But after the first review and some implementation experience, I'm sure that others will start hacking on what we've done to find holes. :-)
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.If only KMail S/MIME wasn't a mess. :)
And we'll do better with S/MIME than the email world has done? Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
