[Security] TLS Certificates Verification
js-xmpp-security at webkeks.org
Wed Aug 20 12:53:17 CDT 2008
Am 20.08.2008 um 19:43 schrieb Peter Saint-Andre:
> That is a very big if.
What would be the problem with contacting Google?
> TLS has undergone many many years of cryptanalysis, hacking
> attempts, and incremental improvement. One crytpanalysis does not
> make a secure protocol.
Yeah, but that would be a start. Stating it is not several years old
and thus can't be good is very, very conservative. We could also say
Jabber can't be good because it's not as old, tested and used as IRC…
> 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).
I was talking about c2c here.
> 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).
Let me summarize:
* There is no client using it.
* There is not even a XEP for it yet.
* Clients would need to be able to handle a second stream, that is
inside another stream.
* Some clients may need a lot of changes for that.
So, how could we have that today? Today, we already HAVE ESessions. :)
I assume it's at least half a year until we have the FIRST client to
implement it. And then we will the the real world problems that you
don't think of in theory, whereas ESessions is already in use in the
> 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.
Yeah, I agree that this is pretty bad, it even breaks compatibility if
you just sign a message.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: This is a digitally signed message part
Url : http://mail.jabber.org/pipermail/security/attachments/20080820/88b835e1/attachment.pgp
More information about the Security