ietf-mailsig
[Top] [All Lists]

RE: In response to Housley-mass-sec-review

2005-02-25 18:24:40

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







<Prev in Thread] Current Thread [Next in Thread>