[jdev] end-to-end encryption -- making it happen

[Peter Saint-Andre]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20070109/f40c4ae3/attachment-0002.bin>