Subject: Re: Client-side revocation checking capability

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 05 Sep 2000 10:02:59 -0600

David, I agree with you completely.

But at the risk of arguing in circles, I would appreciate your thoughts on the need to do CRL checking of web site addresses, at least for the majority of applications.

Presumably there are two reasons why a web server's certificate would ever be revoked:

1.  The key has been compromised somehow, and (this is bit of a stretch), the organization knows that it has been compromised.

2.  The information contained in the certificate is no longer valid.

Now, since SSL downloads the certificates to be used to validate the session (they aren't obtained out of band somehow), I would contend that if the organization knows it has been compromised, it would immediately stop using that key and certificate  go get a new one, and use that one instead.

Likewise, if for example Land Rover wants to change their name from something like "Land Rover, a subsidiary of BMW" to "Land Rover, a subsidiary of the Ford Motor Company," they would just get a new certificate and start using it.

Now, I don't deny the possibility that VeriSign, upon hearing that Ford had bought Land Rover, might take it upon themselves to unilaterally revoke a certificate that identifies them as belong to BMW, but I think it is exceedingly unlikely.  In fact, it is rather hard for me to imagine ANY type of circumstance other than outright, blatant fraud of the most egregious kind that would cause VeriSign to take such unilateral action -- they would almost surely go the cease and desist route, rather than subjecting themselves to a potentially huge suit for damages by unilaterally revoking a certificate. (I'm only using VeriSign as the example here because of their dominance int he server certificate market.)

So that leaves us with the key compromise possibility.

Now, in order to somehow benefit from a key compromise, the perpetrator would have to: (1) first install the compromised key on a server somewhere, and then (2) spoof or otherwise divert the DNS routing so that requests to www.whitehouse.gov go to say  www.dirtytricks.com. But assuming that the legitimate organization knows about the key compromise, they would be on the lookout for such trickery, and would presumably notify the DNS naming authorities to reject any attempt to modify the IP routing for their DNS name.

But putting up a server at a given IP address that contains a stolen key would effectively constitute a smoking gun pointed directly at the instigator's head, to mix a metaphor.  It provide prima facie evidence that they were responsible for the key theft.

OK, I'll grant that this isn't absolutely airtight and foolproof, and that for some really, really important transactions it might be nice to actually check the web server's CRL, "just in case".  But assuming that you aren't involved in million dollar transactions, the risk seems very slight, and certainly acceptable to most users.

Do you agree with this analysis?

Bob

>>> "David P. Kemp" <[email-masked]> 09/01/00 10:53AM >>>

> From: [email-masked] 
>
> Now looking at possibly a trivial occurance of relying party checking ... 
maybe
> only a trivial 99.99999999999999% of all relying party "checking" currently
> going on ... it would appear that the most common occurance of a relying party
> checking something is a SSL relying party checking a domain name.
> 99.999999999999% of all such checking might not seem like a valid situation to
> consider.

What is the threat that the PKI is addressing?   My assumption is that
in 99.99999999% of the cases the company hosting the web server is interested
in preventing the following:

1) user sees "www.companyA.com" on an advertisement and types it in, or
   clicks a link.

2) DNS has been hijacked, the user connects to a bogus server, and the
   user gives up his personal info to the bad guy.  Or the user sees a
   parody of www.companyA.com, or worse.

A server certificate issued by a CA to the company binds a company name
(real world and/or DNS) to the company's private key.  If DNS has been
hijacked, the bad guy still can't impersonate the company web site.
I'd say that 99.999999% of the relying party checking involves seeing
the company's legitimate content; the DNS name is largely irrelevant
for the user's purposes.  The user could type an IP address, or any one
of a number of DNS names, and as long as he gets to the company's
information he couldn't care less how he got it.

In fact, including DNSnames in relying party (browser) checking causes
unnecessary problems with virtual hosting. "www.CompanyA.com" should be
a DNS *Name*, something the user types when he wants to see CompanyA's
information.  It shouldn't be any problem if CompanyA's information is
actually being served from https://www.hosting-service.com/account51/;
the only thing that matters is that the user can be referred from what
he types to where the information resides, and that the legitimate
information provider has CompanyA's private key.

 * DNS security should be about binding DNS names to IP addresses, and 
   should have nothing to do with EE keys.
 * PKI security should be about binding names (DNS, rfc822, or a real
   world brand name - "Ford Motor Company") to keys.  The CA's responsibility
   is to ensure that the brand owner and the key are properly matched -
   this is far beyond the scope of a DNS administrator's duties.
 * application security should be about protecting whatever is meaningful
   about the user with the user's private key.  In the case of web servers,
   what is meaningful is the company's content, not a DNSname.

If you try to take shortcuts (by combining DNS and PKI, for example),
you prevent useful things from happening.  DNS security supports
infrastructure availability; PKI supports application security.
Unnecessarily sacrificing web server functionality for security just
gives security a bad name.  And increasing the DNS administrator's
workload hinders the adoption of simple yet valuable name-to-IP
security.

---

From: Dennis Glatting <[email-masked]>
Date: Tue, 05 Sep 2000 10:54:53 -0700

Bob Jueneman wrote:
	[snip]

> But putting up a server at a given IP address that contains a stolen key would effectively constitute a smoking gun pointed directly at the instigator's head, to mix a metaphor.  It provide prima f…

I'd like to point out that there is no Internet routing authority,
naming authority, or police. Bogus routes can be inserted into the
Internet infrastructure, DNS information changed (look at NSI), and
DNS spoofed. Additionally, a smoking gun is of little relevance if the
site in question is a compromised host or located in a jurisdiction of
little legal consequence, such as Russia, Croatia, or as recently
demonstrated by the ILOVEYOU virus, the Philippines.

> OK, I'll grant that this isn't absolutely airtight and foolproof, and that for some really, really important transactions it might be nice to actually check the web server's CRL, "just in case".  B…

All that is required is many transactions of less than USD $50 --
below the credit card companies' radar. This technique has been
perpetrated several times. Immediate examples include a Californian
ISP and a porn shop that kept changing names and shifting locations
globally.

It happens.