[Security] TLS Certificates Verification

Eric Rescorla ekr at rtfm.com
Wed Aug 20 11:17:15 CDT 2008

On Wed, Aug 20, 2008 at 9:07 AM, Dave Cridland <dave at cridland.net> wrote:
> On Wed Aug 20 16:09:05 2008, Jonathan Schleifer 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?
> We're not, always.
> Ekr, for instance, has been talking in terms of PAKE, a shared secret, and
> session resumption, in a pretty convincing way. So convincing, in fact, one
> could be forgiven for thinking he knew a thing or two about this stuff.
> In fact, I think certificates are actually the best approach, because
> they're better understood, the IPR impact is clearer, they provide a wide
> range of options for initial and subsequent authentication, and both users
> and developers are more exposed to them, hence more likely to accept and
> trust them. I think we have a solid base there from leap-of-faith to
> fingerprinting to work with.
> Technically speaking, Ekr's suggestion is probably the better one, but I
> think it's not so much better that the benefits outweigh the political and
> usability advantages of self-signed certificates.

I'm not sure I have a suggestion, actually, I'm just exploring the space...

To the extent I have a suggestion, it's this:

- The protocol should use public keys as the basis for trust. I.e. Alice
  should store "Bob: PubKey=XXXX" or "Bob: Cert=XXXX". This is
  maximally compatible with a variety of out-of-band establishment

- There should be a variety of mechanisms for establishing the binding
  between Bob and his key/cert.
  + Any system based on long-term public
     keys is automatically compatible with key fingerprints and leap-of-faith.
  + Any system which can carry certificates is compatible with 3rd-party
  + There are a variety of potential ways to integrate an initial password
     as a bootstrap for establishing the user/key binding. Which one is
     most convenient depends on the protocol and software environment.
     A number of these are probably compatible with existing protocols.
  + If an SAS is desired, it should be used as a bootstrapping mechanism
     for establishing the user/key binding above.


More information about the Security mailing list