[Security] TLS Certificates Verification

Eric Rescorla ekr at rtfm.com
Tue Aug 19 07:20:39 CDT 2008


On Tue, Aug 19, 2008 at 1:09 AM, Jonathan Schleifer
<js-xmpp-security at webkeks.org> wrote:
> Am 18.08.2008 um 23:21 schrieb Peter Saint-Andre:
>
>> Except that it's an unanalyzed technology.
>
> But it wasn't analyzed with IM in mind, but stuff like HTTPS or IMAPS. For
> Jabber, we have traffic that is human generated,which allows a lot more of
> attacks. I already named a few of them on the standards list.

Hmm... Perhaps you could point me to some. Most of the analysis I have
seen done of TLS was generic, not limited to (e.g., the 1996 Wagner and
Schneier paper) was generic.




>> Plus using TLS enables us to re-use code for the client-to-server,
>> server-to-server, link-local, and end-to-end scenarios. I consider that a
>> good thing.
>
> That means that people who are NOT familiar with crypto will use libraries
> like OpenSSL. Using them in the wrong way can make all encryption completely
> useless.
>
> With ESessions, Brendan Taylor offered to write a libesessions, a library
> that you just need to pass the stanzas and it will return the encyrpted
> stanzas. Nothing developers could do wrong here.

And of course, this library will be totally perfect, not need any maintenance,
etc.

I'm certainly sensitive to the complaint that libraries like OpenSSL
give the programmer
too much freedom, but that seems to me to be primarily an issue of providing an
appropriate wrapper API. I don't see that that motivates designing an
entirely new
protocol which must then be maintained, and also requires a new implementation
that must itself be maintained. This has proven to be a significant amount of
work for all the COMSEC protocols of which I am aware, and given that XSF's
expertise isn't primarily in COMSEC, I don't see any reason to expect that its
experience would be different.

-Ekr


More information about the Security mailing list