[Security] TLS Certificates Verification
stpeter at stpeter.im
Wed Aug 20 12:43:32 CDT 2008
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
TLS has undergone many many years of cryptanalysis, hacking attempts,
and incremental improvement. One crytpanalysis does not make a secure
> 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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20080820/737cae7a/attachment.bin
More information about the Security