Subject: Re: Client-side revocation checking capability

From: "David P. Kemp" <[email-masked]>
Date: Fri, 1 Sep 2000 12:53:20 -0400 (EDT)

> 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: [email-masked]
Date: Sat, 2 Sep 2000 11:24:05 -0700

some general comments and three example/scenerios

I have not been commenting at all about how you might want the world of
certificates to behave.

I've only been making observations and assertions about the trivial case that
accounts for 99.9999999999999999999% of the current real world situations where
a client compares some information against something in a server certificate
(namely an SSL session involving a domain name in a server certificate)

While there may be problems with client browsers checking for domain name in a
server certificate for SSL session setup .... then there are problems.

If server certificates can be done some other way, then server certificates can
be done some other way. It doesn't negate the comments, observations and
assertions about the way the specific trivial case operates, namely the trivial
case involving 99.99999999999% of the current activity where clients do
something with a server certificates.

The observation is that for the trivial case outlined ... namely the one in the
real world today which accounts for 99.9999999999% of where a client is doing
something with server certificates (namely SSL and domain names) .... that
adding public key for domain name authentication can make that current use of
server certificates for the specific case outlined (involving 99.999999999999%
of today's activity involving server certificates) redundant and superfulous.

There could be all sorts of non-trivial cases for certificates to which that
observation doesn't apply. It was specifically made as an observation for that
specific case. These other non-trivial cases ..... which possibly accounts in
aggregate for possibly <0.0000000000001% current day server certificate
activity.

I believe that public/private keys are about authentication (at least in the
digital signature case, things like FIPS186). The SSL use of server certificates
(the trivial case that currently accounts for 99.999999999999% of current real
world activity involving clients doing something with server certificates).

DNS is both about availability as well as trust, not only is the information
readily available, but can the information also be trusted. One way of improving
the trust in DNS information is the shortcut that SSL protocol took with SSL
server certificates. Another way in improving the trust in the DNS information
is by adding public keys (and digital signatures) to DNS as part of an
authentication feature.

The issue isn't that the domain name to IP-address operation isn't necessary.
The observation is that when registering a domain name there is already quite a
bit of information that is registered (some people may have forgotten but there
are things like name/address/phone# for technical contact, administrative
contact, billing contact ... don't forget they need to bill somebody for the
registration). The further observation is that there are currently integrity
problems with the current domain name infrastructure and trust is a big issue
here. Adding public keys to the current registration process is actually quite a
small incremental increase (at least for ECC keys) in the amount of data. The
percentage increase in the process for registering public keys isn't large.
Given all the issues about trademarks with respect to domain names .... the
administrative load is increasing totally independant of whether public keys are
being registerred. Furthermore, because of the issues like domain name
hijacking, administrative load is also increasing for better authenticating that
only the domain name owner is allowed to make changes.

The registration and use of public keys for domain name infrastructure
authentication can actually reduce the increases in administrative load.

The domain name infrastructure is very much about authentication and trust ...
not just about mapping a domain name to an ip-address. Some people may only have
limited experience with a small subset of the domain name instructure ... namely
the resolved operation that returns an ip-address for a given domain or host
name. However there are huge issues involving quite a bit of administrative
workload involving who owns domain names and who is allowed to operate on
information associated with domain names.  No realizing that is a very myopic &
narrow view of how the current internet and web environment actually functions
on a day to day basis. The domain name infrastructure very much has to know that
the "domain name" owner is the entity that is allowed to change, update, &/or
delete information associated with a domain name. Nominally such "knowing"
involves some sort of authentication function. Registering passwords &/or PINs
is one way for providing for authentication. I think that many people would
agree that registering public keys and using digital signatures can be a much
better authentication process (than passwords or PINs).

Now, there might be an issue of adding a public key to all current standard DNS
responses (which might just involve a single IP-address). Standard DNS today
allows for queries that return information in additon to host ip-address. I
contend that modifying existing SSL protocol to do a DNS query for both an
IP-address and a public key .... would represent an overall reduction in SSL
protocol web bandwidth used, server processing and client processing (aka server
doesn't transmit one or more certificates, client doesn't validate one or more
certificates in order to decide if it can use the server's public key).

One of the assertion is that while the SSL server certificates were to address a
trust deficiency in the DNS infrastructure ..... those same SSL server
certificates are dependant on trusting the DNS infrastructure as the final
authority on who owns a domain name.; That, in fact (because of issues like
domain name hijacking) that even SSL server certificates would benefit from
improving the trust in the DNS infrastructure. One way of improving trust in the
DNS infrastructure is to add authentication (via public keys) to various DNS
business processes. The assertion is that if public keys are added to that
infrastructure ... then that makes public keys & domain names in SSL server
certificates redundant and superfuloous. Furthermore, if it is no longer
necessary to have SSL server certificates for public keys and domain names, then
the SSL server certificates and also redundant and superfulous.

I've still not commented about any of the non-trivial cases of server
certificates that possibly represent <0.0000000000001% of the total current
activity where a client is checking some information in a server certificate.
I've tried to restrict myself purely to the trivial case which represents
99.999999999999% of all current activity where a client is checking some
information in a server certificate.

I've tried to not comment anything about general application security or PKI or
whatever. I've tried to restrict myself purely to the trivial case which
represents 99.99999999999% of all current activity where a client is check some
information in a server certificate.

For that particular trivial case, I've asserted that adding public keys to DNS
for authentication (within FIPS186), then the trust in the DNS information can
be improved (and make it much more difficult to do things like hijack a domain
name).  Furthermore the server certificates for the trivial case involving
99.9999999999% of all current activity where a client is checking some
information (i.e. domain name in an ssl certificate) are also at risk if domain
name is hijacked (i.e. I can hijack a domain name and then get an SSL
certificate for that domain name).  Therefor these SSL certificate
infrastructures also need the trust in the DNS infrastructure improved. My
observation that addressing the DNS infrastructure trust issue with public keys
and authentication ... in order to remove the risk to the SSL certificate
infrastructure also can make the SSL certificate infrastructure redundant and
superfulous.

Again, I'm not making any general observations about PKIs or PKIXs. I'm not
making any observations about the current non-trivial cases involving server
certificates that account for <0.00000000000001% of the current situations where
clients are currently checking some information in a server certificate. I'm
only making the observations about the trivial case which accounts for
99.9999999999999999% of the current situations wehre clients are currently
checking some information in a server certificate.

I'm not making any suggestions about combining DNS and PKI. I'm making
suggestion that public keys can be added to domain name registration for
authentication purposes (the person that registers the domain name and the
ip-address(es) can operate on the entry). The observation is that the
registration of a public key when the domain name is registered can improve the
trust in the DNS infrastructure by authentication operations. Furthermore, DNS
can provide (in real time) all information registered for domain name entry ...
to whatever decree of trust that DNS information is trusted. If the registered
information includes a public key ... then that public key can be provided to
clients at the same time it provides any other registered information (like
IP-address mapping for a domain name).

To the degree that the domain name can be trusted .... the public key can be
trusted to the same degree.

!!!!!!!!!  To re-iterate, the following discussion applies only to the trivial
case involving 99.9999999999999999% of the current situations where a client is
checking some information in a server certificate  (namely the SSL protocol
involving the domain name SSL server certificate).

!!!!!!!!!   The following discussion does not (necessarily) apply to any
non-trivial cases involving <0.00000000000001% of the current situations where a
client is checking some information in a server certificate (including any
non-SSL server certificate for merchant/company names).

=================
scenerio/example 1

So specifically for the SSL server certificate case, if a public key is needed
for authenticating a server at a specific domain name:

A CA can get a request to issue a domain name SSL server certificate

A CA can contact the domain name registration authority as to the validity of
the domain name ownership

The degree that a domain name SSL server certificate can be trusted is to the
degree that the domain name registration authority can be trusted

Assuming that the domain name registration authority can fix many of its  trust
issues with authentication, digital signatures & public keys

Then the assertion is that the trust in the domain name  SSL server certificate
can be no better than the trust in the domain name registration authority public
keys

If the trust in the domain name SSL server certificate can be no better than the
trust in the domain name registration authority public keys, clients can use
"real-time" domain name registration authority public keys in lieu of domain
name SSL server certificate public keys

If 1) domain name SSL server certificate public keys are at the same trust level
as the domain name registration authority public keys and 2) the domain name
registration public keys are available and updated in real time, while 3) the
domain name SSL server certificates are manufactored at some period in the past
and can be stale or incorrect, then I contend that the domain name registration
public keys actually are actually more trusted because of the real-time
availability and update.

Showing that the domain name registration public keys are more trusted than the
domain name SSL server certificates and the domain name SSL server certificate
public keys also shows that the domain name SSL server certificate public keys
are redundant and superfulous. If the domain name SSL server certificate public
keys are redundant and superfulous then the domain name SSL server certificates
are redudant and superfulous (for the specific trivial case under discussion
which accounts for 99.999999999999% of current real world cases where client is
checking some information in a server certificate).

=================
scenerio/example #2

so now lets look at adding a CA PKI to the domain name  infrastructure to
authenticating domain name owners for domain name transactions. this is going to
be similar to relying-party-only PKI used by various banks (for liability and
privacy reasons.

1) domain name infrastructure sets up a CA PKI that registers domain name owner
public keys as part of domain name registration.

2) the CA PKI is setup to manufactor an sign domain name infrastructure relying
party certificate, basically the name is the domain name bound to the domain
name owner's public key and whatever other domain name related information that
the infrastructure wishes to put in the certificate (possibly ip-address).

3) The CA PKI stores the original of the certificate in the associated domain
name entry in compressed form (i.e. un-encoded, non-unique information removed,
etc)

4) The CA PKI returns a copy of the certificate to the domain name owner.

5) The domain name owner a) generates domain name owner transactions, b) signs
the transactions, c) sends the transaction and signature with a copy of the
certificate appended to the domain name infrastructure

6) For efficiency sakes, the appended certificate is compressed, all fields
known to already be in the possession of the relying party are removed. Since
the relying party already possesses the original manufactored certificate (and
the domain name owner only has a copy of that same certificate), the appended
certificate is compressed to zero bytes.

7) The CA PKI knowing that the domain name owner will alwas compress the
certificate to zero bytes actually sends the domain name owner a pre-compressed
certificate of zero bytes (saving the domain name owner the overhead of having
to do this on every transaction).

8) All domain name transactions are authenticated using standard CA PKI digital
processes and with valid compressed zero-byte certificates appended to every
transaction.

for more discussion on this technique of valid compressed  zero-byte
certificates see:

http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2

==================
example/scenerio #3

examining the domain name infrastructure it appears that it has alwas been a
certification authority for binding of information since its inception.

The primary differences

1) OCP ... it has alwas supported an online certificate protocol (as opposed to
an online certificate status protocol) with the ability to return the
certificate of bound information in real time (some modulo regarding the trust
level of these "certificates"). these weren't public key infrastrucutre  or
public key certificates and they were presumed to have extremely short
lifetimes. The protocol did support requesting a variety of bound information,
domain name to ip-address as well as domain name to various other kinds of bound
information

2) SLDDAP ... the super light weight distributed directory protocol. In support
of OCP the domain name infrastructure also supported the super light weight
distributed directory protocol where the bound information for the DNS
"certificates" were distributed in for efficient and scallable real-time access.

In conjunction with scenerio #2 where the domain name infrastructure adds a CA
PKI (with the registration of public keys and relying party only domain name
owner certificates) to use the OCP protocol options to request a real-time
certificate containing the bound information (from the domain name
infrastructure ) containing a) domain name, b) ip-address, c) domain name
owner's public key.

Given that this form of domain name infrastructure certificate contains public
key in the bound information then one could consider it a public key
infrastructure certificate (modulo peoples'  opinion regarding the current
integrity and trust in the domain name infrastructures' bound information and
whether or not this is a pki or a PKI).

So lets return to the scenerio #1 trivial case (the situation that covers
99.9999999999999% of the current clients checking some information in a server
certificate).

For the SSL protocol case which would seem to have the higher integrity:

1) current SSL domain name certificate manufactored at some point way in the
past (and possibly containing stale information) which is dependant on the
domain name infrastructure for the validity of the information.

2) a DNS OCP real-time public key infrastructure from the domain name
infrastructure and is dependant on the domain name infrastructure for the
validity of the information.

Both certificates have their fundamental integrity and trust built on the same
domain name infrastructure:

a) one certificate is manufactored way in the past and has increasing
probability of containing stale information.

b) the other certificate is manufactored in real-time in response to an
immediate request for bound information.

"David P. Kemp" <[email-masked]> on 09/01/2000 09:53:20 AM

Please respond to "David P. Kemp" <[email-masked]>

To:   [email-masked]
cc:    (bcc: Lynn Wheeler/CA/FDMS/FDC)
Subject:  Re: Client-side revocation checking capability

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 11 Sep 2000 13:12:54 -0400 (EDT)

Bob, you ask "is there a significant security benefit to doing revocation
checking on web server certificates?"  I'll only consider the first reason,
key compromise, since if it provides a positive answer, no other reasons
need to be considered.

PKI serves the relying party, not the subscriber.  If I connect to a web
site, do I get any benefit from checking for certificate revocation?  What
do I lose if I trust a cert whose private key has been compromised?
Obviously, if I'm just surfing around, I don't lose anything.  It doesn't
harm me if I see the content of "whitehouse.com" when I really wanted
"whitehouse.gov".  But if I'm buying something with a credit card, I
might want to do whatever is possible to prevent my card from being used
fraudulently.

You are correct, there needs to be
  1) a detected compromise, and
  2) a MITM,
for CRLs to provide useful protection against key compromise.
DNS spoofing is certainly not the only way for an attacker to insert
himself somewhere between a client and a server on the Internet, so
even if DNSsec were 100% implemented and effective, unauthenticated SSL
(a session where the user clicked "Yes" to ignore a path validation
problem) would not guarantee a secure connection to the desired
server.

I don't agree that the pertinent question is "is this a million dollar
transaction?".  The question is "does the potential benefit of checking
a CRL exceed the cost of checking it?".  If I had $0 liability for
credit card fraud if I followed best commercial cert validation
practice, and $50 if I ignored it, then I'd probably follow it even if
the probability of loss were very small.  Unless of course following
"best practice" caused a significant slowdown, in which case I'd turn
off revocation checking entirely or get in the habit of clicking "Ignore"
when the (hypothetical) "Fetching CRL ..." window pops up.

So how to make revocation checking invisible enough that users don't
turn it off?  Bob Moskowitz already gave the answer to that: partition
so that CA/server CRLs remain tiny (empty 99.999999% of the time), and
pass them from server to client along with certs in the TLS handshake
so they don't cause any additional delay.

Regards,
Dave

> Date: Tue, 05 Sep 2000 10:02:59 -0600
> From: "Bob Jueneman" <[email-masked]>
> To: <[email-masked]>, <[email-masked]>
> Content-Disposition: inline
> 
> 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 >>>
> 
> > Now looking at possibly a trivial occurance of relying party checking ...m
>  aybe

---

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 11 Sep 2000 16:16:57 -0600

David,

It's always useful to get someone else's perspective on these kinds of 
issues, especially when the issue is not really technical but cost/benefit.

Paraphrasing what you've said, and playing it back to be sure we are 
on the same page, I conclude that since Visa, MasterCard, and
American Express have effectively lowered the liability for consumers for 
electronic transactions to $0, waving the Reg. E/Reg. Z $50 limit of liability,
my only risk in the event of a credit card scam on the Internet is the hassle 
factor of notifying my bank that I didn't make the purchase in question.
And since checking CRLs still doesn't guarantee that an employee of
the merchant can't rip off my card (or the waitress at my favorite restaurant), 
if CRL checking slows me down by more than a fraction of a second, it 
probably isn't worth doing.

On the other hand, if I am logging on to some other type of web server,
in particular one where the merchant/bank is NOT collecting a percentage of 
the transaction,. and therefore cannot be quite so forgiving with respect to 
poor security on my part. perhaps, then CRL checking might be quite important.

For example, if my bank or my e-trade broker provides an SSL session to protect
my password or other form of authentication, and someone puts up a bogus 
site that compromises that password, then the limit of my liability may be the 
amount I have on deposit (or even more, if someone sells sort and I can't 
cover it.)

Likewise, if I am consulting my attorney and divulge the details of some heinous
crime, and in reality I'm talking to the District Attorney, I could end up with a 
lot more than just a financial cost.

I do like Bob Moskowitz's solution, and hadn't heard of it -- pass a 
current CRL along with the TLS certificate chain, and make sure that the 
CRL is nearly always empty, so that an excessive amount of time
is not consumed in validating the certificate chain.  Do you know where
that approach stands in the standards track for TSL?

On the other hand, sending the same certificate chain down the line every 
time I log on to Amazon.com is really wasteful of bandwidth. I would like to 
have the option of only downloading the certificates, and the CRLS (and/or 
OCSP response) if my relying party software finds it necessary.  Most of the time
those certificates should either be cached by the relying party, or in a directory 
or other form of cache that can be accessed locally, and quickly.

Regards,

Bob

>>> "David P. Kemp" <[email-masked]> 09/11/00 11:12AM >>>

Regards,
Dave

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 12 Sep 2000 08:58:50 -0400 (EDT)

> that approach stands in the standards track for TSL?

Bob proposed it here on Sept 1 in conjunction with IPsec.
No specific mechanism has yet been proposed for TLS, but there
is current discussion of defining a protocol extension mechanism.
Once extensions have gelled, it would be appropriate to define a
CRL request extension with the server CRL in the response.

An alternative would be to modify the existing TLS certificate list
to include CRLs, but that is less desirable assuming extensions happen.