On Fri, 2005-02-25 at 16:20 -0800, Hallam-Baker, Phillip wrote:
What is either disingenuous or ignorant is to discuss the problem of CRL
handling without mentioning OCSP which is a technology that has been
operational since 1998 or so. The first version of Authenticode included an
OCSP component (albeit one based on a now obsolete standard).
Notes from RFC2560:
X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP
---------------------
5. Security Considerations
For this service to be effective, certificate using systems must
connect to the certificate status service provider. In the event such
a connection cannot be obtained, certificate-using systems could
implement CRL processing logic as a fall-back position.
A denial of service vulnerability is evident with respect to a flood
of queries. The production of a cryptographic signature significantly
affects response generation cycle time, thereby exacerbating the
situation. Unsigned error responses open up the protocol to another
denial of service attack, where the attacker sends false error
responses.
The use of precomputed responses allows replay attacks in which an
old (good) response is replayed prior to its expiration date but
after the certificate has been revoked. Deployments of OCSP should
carefully evaluate the benefit of precomputed responses against the
probability of a replay attack and the costs associated with its
successful execution.
Requests do not contain the responder they are directed to. This
allows an attacker to replay a request to any number of OCSP
responders.
The reliance of HTTP caching in some deployment scenarios may result
in unexpected results if intermediate servers are incorrectly
configured or are known to possess cache management faults.
Implementors are advised to take the reliability of HTTP cache
mechanisms into account when deploying OCSP over HTTP.
-----------------
The review only mentioned the problems required to frequently poll
Certificate Revocation Lists (CRL). Whether done as a batch process, or
as a poll (as indicated within the review), this added overhead would be
problematic. The concern was with respect to the size of this data, in
addition to added traffic. In a future draft, I will add a reference to
RFC2560 to address your concern of not being comprehensive.
This is still compared to a mechanism, where in the majority of cases,
no query for a revocation status would be required. Where a query is
made, it would involve a single address record when the account has been
revoked, and no record otherwise. The signature had already been
confirmed, so this mechanism only confirms whether the particular
account remains valid when the message is from a foreign domain. This
is to prevent the potential for a canceled account staging a replay
attack.
-Doug
-----Original Message-----
From: Mark Baugher [mailto:mbaugher(_at_)cisco(_dot_)com]
Sent: Friday, February 25, 2005 6:02 PM
To: Hallam-Baker, Phillip
Cc: 'Douglas Otis'; Dave Crocker; MASS WG
Subject: Re: In response to Housley-mass-sec-review
I think it's disingenuous to claim that MASS PKI problems have been
solved when nothing on this scale has ever been deployed.
Mark
On Feb 25, 2005, at 1:07 PM, Hallam-Baker, Phillip wrote:
Perhaps you should take the time to study the developments in PKI
since 1995
before publishing the draft.
In particular you should look at OCSP which entirely eliminates the
issues
you raise wrt CRL size and has been deployed at very large
scale. You
should
also look at XKMS which has similar operational
requirements to OCSP
but
provides support for the complete key lifecycle and eliminates the
need for
certificates.
Clearly a key centric PKI that is built on the legacy DNS system is
not going to be as satisfactory as a PKI as a purpose built Web
Service such as XKMS. There is however no reason why we
cannot use DNS
for the cases it can
support and migrate to XKMS for more comprehensive support.
Given that certificate revocation technology is built into Windows
since Win
2000 the CA industry is well aware of the operational difficulties
raised by
CRLs.
-----Original Message-----
From: owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of
Douglas Otis
Sent: Friday, February 25, 2005 3:30 PM
To: Dave Crocker
Cc: MASS WG
Subject: Re: In response to Housley-mass-sec-review
Here is a first pass at putting together a document. Any
feedback is
welcome.
As this was completed beyond the IETF draft cutoff date,
these links
reference the draft.
http://www.kelkea.com/ietf/draft-otis-mass-reputation-00.html
http://www.kelkea.com/ietf/draft-otis-mass-reputation-00.txt
-Doug