[Security] TLS Certificates Verification

[Peter Saint-Andre]

Jonathan Schleifer wrote:
> Am 20.08.2008 um 19:08 schrieb Jonathan Dickinson:
> 
>> Good suggestion. Seeing as Google is one of the sponsors I don't see 
>> why they wouldn't.
> 
> 
> Yeah, and if we have a cryptanalysis, 

That is a very big if.

> what reasons are there against 
> ESessions? 

TLS has undergone many many years of cryptanalysis, hacking attempts, 
and incremental improvement. One crytpanalysis does not make a secure 
protocol.

> It's already implemented and Brendan Taylor already said to 
> port his Python implementation to C so others can use it, so we will 
> have a library even easier to use as libotr! Would be even far easier 
> for devs to use that lib than to play around with some TLS lib, 

Excuse me, but we already "play around" with TLS libs -- unless you 
hadn't noticed, that's how we do channel encryption right now, and every 
Jabber client under the sun already supports it. It's very attractive to 
use the same underlying technology for encryption of c2s, s2s, and e2e 
streams (whether the latter are link-local or happen over TCP, XMPP, or 
whatever).

> just 
> pass the stanza to the lib and get the encrypted one back :).

And that is different from TLS how?

Jonathan, you don't seem to be listening very well. I suggest that you 
stop beating the ESessions drum for just a little while and take a bit 
of a break to reflect on ekr's posts, read the relevant specs, and think 
seriously about how we could have e2e pretty much *today* in all clients 
using TLS-over-XMPP, reuse *any* existing TLS library, and incrementally 
add new features (e.g., SAS) to TLS if we need them (thus benefiting the 
entire Internet community).

And that's not even to get into the Layer 8 issues of what the IETF 
security mafia might find acceptable -- RFC 3921 requires support for 
RFC 3923 and we need to substitute something reasonable for that ugly 
ugly S/MIME stuff that no one has ever implemented and no one ever will.

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20080820/737cae7a/attachment.bin