[Security] TLS Certificates Verification

Eric Rescorla ekr at rtfm.com
Mon Aug 18 16:34:19 CDT 2008

On Mon, Aug 18, 2008 at 2:21 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> Jonathan Schleifer wrote:
>> Am 18.08.2008 um 21:22 schrieb Dirk Meyer:
>>> That is not an option for me. I want bots to talk to each other. They
>>> can not use the phone.
>> That's why for example ESessions doesn't only provide SAS, but also using
>> public keys. It does not need to use public keys, but it can. This is indeed
>> *VERY* nice as there's no need to generate a key then.
>> I still think that ESessions is *THE* solution for encrypted IM.
> Except that it's an unanalyzed technology. TLS has undergone years and years
> of analysis and hardening. I like the ideas behind ESessions and real
> security folks who've glanced at it seem to think it's not entirely dodgy,
> but that doesn't mean it would withstand a full security analysis.
> 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.
> /psa

So, again, I think it would be best to separate two issues:

(1) What style of authentication you want.
(2) What protocol it's embodied in.

I think we can all agree on the following:
(1) You must have an operational mode that doesn't require certified
public keys.
(2) There needs to be some continuity of authentication mechanism so whatever
     manual authentication stage only needs to be done once.
(3) The manual authentication stage should be as convenient as possible.
(4) The system needs to work with Bots on the other end.

As I indicated in my blog post,
there are a number of potential options, including fingerprints, passwords,
and SAS. Each has some advantages and disadvantages, and it may
be the case that you need to have multiple options.

Speaking as someone who knows COMSEC but isn't really part of the XMPP
community, I would encourage you to try to figure out what *style* of
you want and what the constraints are, and then ask what protocol best suits
or can be made to best suit those needs.

More information about the Security mailing list