[Security] TLS Certificates Verification

Eric Rescorla ekr at rtfm.com
Wed Aug 20 11:10:36 CDT 2008


On Wed, Aug 20, 2008 at 8:09 AM, Jonathan Schleifer
<js-xmpp-security at webkeks.org> wrote:
> Peter Saint-Andre <stpeter at stpeter.im> wrote:
>
>> Please do some research about TLS. It is not limited to using keys
>> (e.g., read RFC 5054).
>
> Then why are we only talking about keys and verifiying keys here, and
> not about secrets and verifiying secrets?

Category errors?

At a high level, we have Alice and Bob. They would like to establish a
secure connection so that Alice knows she's talking to Bob and vice
versa. Each side can locally generate an arbitrary amount of keying
material but that doesn't give you authentication.

We're assuming that Alice and Bob are going to engage in one out-of-band
authentication transaction (fingerprint reading, SAS, SRP, etc.) but would
like to have to only do that once. That means that Alice needs to locally
store some value that she can use to authenticate Bob in the future and
vice versa. To a first order, that value can be one of two things:

- A secret shared by Alice and Bob, and established through the initial
  connection.
- The other side's public key (or a digest of the public key).

Either of these allows Alice in the future to connect to Bob and verify Bob's
identity without another out-of-band transaction.

The traditional approach (used by SSH) is to store the public key. This has
a number of advantages:

- It's directly compatible with fingerprint mechanisms.
- It doesn't require confidential storage, just authenticated storage.
- It doesn't require special protocol accomodation if your protocol already
  supports public keys at all.

That said, the secret storing schemes work as well. In TLS we'd call
this "session caching".

-Ekr


More information about the Security mailing list