[jdev] end-to-end encryption -- making it happen
stpeter at jabber.org
Tue Jan 9 14:24:40 CST 2007
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
> 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.
Jabber Software Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the JDev