Subject: Re: Client-side revocation checking capability

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 14 Aug 2000 11:36:38 -0600

Anders,

There is a lot of practical truth in what you say.

CRL checking certainly seems like a nice thing to do cryptographically, until you consider what the threat is that you are trying to address.

Let's suppose amazon.com's key were compromised somehow. What would happen?  Well, the first thing is that they would call up their CA and get a new certificate, and then download that certificate to any SSL user. So the old certificate and key would be completely out of the picture, and hence no CRL would be needed, much less OCSP.  since they don't use that certificate to sign anything other than SSL sessions, which in which the certificates are sent in line, they don't even need to revoke their old certs -- just stop using them.

The only case where a CRL might be useful in that scenario would be in the case of some fly-by-night mafia.com type of store-front, where the CA might conceivably revoke the certificate for fraud or other cause. However, that would represent a substantial legal liability for the CA, and so that doesn't seem terribly likely in practice.

Since the retail merchant accounts for the overwhelming use of PKI to date (e-mail is just barely beginning to make a dent, and everything else are just pilots, it isn't surprising that the browsers don't enable CRL checking by default. It would merely add lots of delay and processing time.

Bob

>>> "Anders Rundgren" <[email-masked]> 08/12/00 12:02AM >>>
Juan Carlos,

That on-line checking of server-certificates is not standard in browsers is probably
beacuse a revocation is not that likely to happen.  In case of a key compromize at the VeriSign
CA the whole world will be notified and in the case of key compromize in a web-server no
one will know or be notified.  You can steal a web-cert+key from a lousy installation (most are)
in case you have sys-admin rights.   Nothing to do about except tighten up internal security.
And if the host-name is no longer valid (the company filed for bancruptsy) the
server will be taken down some day.

IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where
you may revoke yourself due to loss (of card) or by the company because you got fired.

This is a slightly different answer than you get by asking a typical crypto expert but to my
knowledge they usually know zilch, nada etc. about practical things that may be 100 times more
important than the cryptologic solurtion.  I.e. as long as there are serious practical problems
associated with server-certificates, CRLs etc. would basically add nothing (but delays).

Regards
Anders

---

From: Dennis Glatting <[email-masked]>
Date: Mon, 14 Aug 2000 10:56:39 -0700

Bob Jueneman wrote:
> CRL checking certainly seems like a nice thing to do 
> cryptographically, until you consider what the threat is that you 
> are trying to address.
> 
> Let's suppose amazon.com's key were compromised somehow. What 
> would happen?  Well, the first thing is that they would call up 
> their CA and get a new certificate, and then download that 
> certificate to any SSL user. So the old certificate and key would 
> be completely out of the picture, and hence no CRL would be 
> needed, much less OCSP.  since they don't use that certificate to 
> sign anything other than SSL sessions, which in which the 
> certificates are sent in line, they don't even need to revoke 
> their old certs -- just stop using them.
> 
> The only case where a CRL might be useful in that scenario would 
> be in the case of some fly-by-night mafia.com type of store-front, 
> where the CA might conceivably revoke the certificate for fraud 
> or other cause. However, that would represent a substantial legal 
> liability for the CA, and so that doesn't seem terribly likely 
> in practice.
> 
> Since the retail merchant accounts for the overwhelming use of PKI 
> to date (e-mail is just barely beginning to make a dent, and 
> everything else are just pilots, it isn't surprising that the 
> browsers don't enable CRL checking by default. It would merely add 
> lots of delay and processing time.
> 

I disagree. To access www.amazon.com one uses DNS, which is not secure
and often easy to poison. Consequently, mafia.com can redirect some
number of browsers by poisoning some number of DNS servers, present a
Amazon.COM store front, and use Amazon's cert and private key. If the
browser doesn't check for revocation then the consumer is none the
wiser, at least for a while.

-- 
Dennis Glatting
Copyright (c) 2000 Software Munitions

---

From: Henrik Bergman <[email-masked]>
Date: Mon, 14 Aug 2000 21:24:06 +0200

Dennis,

The case you are discribing is hardly a good example to show why CRL's are needed for server-certificates.
If  www.amazon.com uses unsecure DNS and gets poisoned, the action is hardly the put the stolen cert i a
CRL.

Shouldn't the action be to cure the DNS? If someone can poison the unsecure DNS, shouldn't the long term
goal be to secure the DNS, rather than letting all users check all servers cert in CRL's all the time?

Henrik Bergman
X-OBI

To access  one uses

--
__________________________________________
Henrik Bergman, X-OBI, mob 070-866 87 72
e-mail: [email-masked]

---

From: Dennis Glatting <[email-masked]>
Date: Mon, 14 Aug 2000 12:59:04 -0700

> If  www.amazon.com uses unsecure DNS and gets poisoned, the action is hardly the put the stolen cert i a

Assume we have a fairly crappy DNS server, such as the one serving
pki2.com (mine and hopefully not crappy :). Start nslookup and point
to my server. Tell it to look up information from your custom server
(i.e., ask pki2 to lookup www.whatever.com, a zone delegated to you).
Have your custom server return the sought information plus information
in the extra data segment, such as "www.amazon.com IN A
206.129.5.135". Some servers will cache this extra data without
checking it; others, such as BIND 8.x, will discard and log it. Since
pki2 in this example is crappy then when I query it for 
www.amazon.com I am going to go to 206.129.5.135, not Amazon's real
web site.

In this case we did not poison Amazon's DNS, rather pki2's. If my
browser checked for CRLs then it is likely I will see Amazon's
certificate had been revoked. On the other hand, if www.amazon.com is
spoofed then so can the CRL host address (it's just "extra data").
Then the question becomes what would my browser do if the spoofed CRL
host doesn't answer to a CRL request.

Not perfect but does raise the bar, IMO.

> goal be to secure the DNS, rather than letting all users check all servers cert in CRL's all the time?

I am highly skeptical of DNSsec. Assuming we get the roots signed;
trusted keys embedded in servers; and TSIG to clients, we have to get
all COMs/NETs/whatever to sign their zones and all DNS servers to
upgraded. If all these things do not happen, IMO, DNSsec is fairly
worthless because you are operating in an untrusted environment.
Certainly you can configure your local DNS server as to which zones
are DNSsec'd, which is what is done now, but that list will quickly
become very long and we might as well go back to FTPing HOSTS.TXT.

---

From: Al Arsenault <[email-masked]>
Date: Mon, 14 Aug 2000 21:22:23 -0400

Bob, et alia:

The scenario against which CRL-checking-for-server-certs-in-SSL-sessions
protects is:

- the key for Popular_fictional_site.com is compromised, and whoever has
it sets up a duplicate site, with appropriate DNS spoofs to direct
traffic to the duplicate site

- the legitimate owners of Popular_fictional_site.com realize that the
compromise has occurred, report it, and get a new cert.

- now, along comes Jean User, connecting to Popular_fictional_site.com. 
Quick:  is this the real site, or the spoof?  Both have certs and
matching private keys that trace back to the same trusted root.  If the
client checks the CRL, (s)he will detect that they cert/key offered by
the spoof site is revoked, while the cert/key offered by the legitimate
site will be okay.

Okay, now, how realistic is that threat?  Is that the one against which
you're defending?  Who knows?  But it is one of the threats against
which the revocation mechanism was designed to work.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.