Five Theses on Security Protocols

[Perry E. Metzger]

On Sun, 1 Aug 2010 15:07:46 +0200 Guus Sliepen <guus at sliepen.org>
wrote:
> On Sun, Aug 01, 2010 at 11:20:51PM +1200, Peter Gutmann wrote:
>
> > >But, if you query an online database, how do you authenticate
> > >its answer? If you use a key for that or SSL certificate, I see
> > >a chicken-and-egg problem.
> >
> > What's your threat model?
>
> My threat model is practice.
>
> I assume Perry assumed that you have some pre-established trust
> relationship with the online database. However, I do not see myself
> having much of those. Yes, my browser comes preloaded with a set of
> root certificates, but Verisign is as much a third party to me as
> any SSL protected website I want to visit.

Security is not magic. If you have no pre-existing trust relationship
with some source of information, you cannot get additional trusted
information from that source. You have to have some sort of existing
pre-shared information -- a public or private key and a decision to
believe the information from that source -- to get anywhere.

> Anyway, suppose we do all trust Verisign. Then everybody needs its
> public key on their computers to safely communicate with it. How is
> this public key distributed? Just like those preloaded root certs
> in the browser? What if their key gets compromised? How do we
> revoke that key and get a new one?

I think the "we all trust Verisign" model is a bad one (no particular
slam on Verisign here, I think any "we all trust some third party"
model is bad.)

However, you are asking an important question, which is, how do we
replace compromised keys in our configuration files?

This depends a lot on the application. If we're talking about a single
administrative domain (say a few thousand machines inside a company
that are all managed by the same small group), you push out a new
config file. If we're talking about, say, a banking application where
lots of people have the bank's key in the config for their software,
the protocol either has a way of rolling over to the "next key" or you
are forced to send all the users new smartcards or USB keys or what
have you, which is a good incentive to have a means in your protocol
for moving to the next key.

As for the case of "everyone on earth trusts third party X", except
for something like the DNS, I see no reason or benefit in such a
system at all.

> We still have all the same problems with the public key of our root
> of trust as we have with long-lived certificates. Perry says we
> should do online checks in such a case. So which online database can
> tell us if Verisign's public key is still good? Do we need multiple
> trusted online databases who can vouch for each other, and hope not
> all of them fail simultaneously?

No. I think you're not focusing on real applications here. You're
instead thinking far too abstractly.

Say, for example, we're talking about some credit card processor's
public key that is used by all their validation terminals. Presumably
they need some sort of update protocol. However, that protocol does
not need to involve certificates and is not a matter of global
concern. There should be very few cases where a key is a matter of
global concern -- I think having keys be a matter of global concern is
something of an architectural error.

> Another issue with online verification is the increase in traffic.
> Would Verisign like it if they get queried for a significant
> fraction of all the SSL connections that are made by all users in
> the world?

I think the "Verisign is the standard of all truth" model is broken,
but lets consider what you're saying for a minute.

If Verisign is indeed the "standard of truth", then how could we do
anything else? If we don't check a key with Verisign at least every
few hours, then how can we ever have meaningful revocation? Whether
you think that Verisign wouldn't "like" this or not, there is no other
choice given the model you are presenting. Either revocation is
impossible or people make online checks.

Perry
-- 
Perry E. Metzger		perry at piermont.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com