Subject: RE: Signing Untrusted SCVP?

From: "Dave Engberg" <[email-masked]>
Date: Fri, 2 Apr 2004 17:32:30 -0500

An attacker with the ability to intercept your SCVP calls and send back
spoofed responses has a more obvious way to deny service ...

More seriously, I think we agree that there should absolutely be an
option in the protocol to allow a client to request a signed response,
and for the server to provide it.  But by making this an absolute hard
requirement for every client-server pair, you are permanently preventing
the SCVP protocol from being used with any caching or pregeneration at
the server level when used for pure DPD, and you're adding 150 bytes and
50 ms onto every response (plus $20k for a FIPS HSM, if you're serious).

Think of pure DPD as an optimized mechanism for doing certificate
lookups, as an alternative to LDAP.  Previously, PKI standards have not
forced every LDAP lookup to use authenticated SSL tunnels, because most
clients derive their security from the signatures on the retrieved
objects rather than the transport mechanism.  The gratuitous requirement
for SSL on every LDAP query would just further reduce performance and
increase costs for PKI deployments.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Friday, April 02, 2004 4:45 PM
To: Dave Engberg
Cc: [email-masked]
Subject: Re: Signing Untrusted SCVP?

Dave,

I agree that one might not want to invest as much effort and money in
securing a DPD server as a DPV server. But that does not necessarily
translate into removing the need for signatures on responses from such
servers. If responses from a DPD server are spoofed, a client may be
subject to a form of DoS attack, as it tries to make use of bogus certs
formed chains intended to maximize the amount of crypto processing the
client does, before realizing that the chain is bad. 
Or certs might be returned that conflict with certs from some other DPD
server.  Without signed responses it could be very hard to determine
what went wrong and what servers ought to be avoided, based on bad
behavior.

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 3 Apr 2004 00:03:23 -0400

Steve:

I do not see a particular reason to require a DPD Server to be held to a 
higher standard then a Directory Server.  We do not require signed responses 
from Directories.  Both being stationary servers, are equally prone to 
hacking.  Also, in order to verify the DPD Server signature, the client may 
get into another problem of obtaining a path for the DPD Server itself, which 
may not be a circular problem, but will degrade performance

> translate into removing the need for signatures on responses from 
> such servers. If responses from a DPD server are spoofed, a client 
> may be subject to a form of DoS attack, as it tries to make use of 
> bogus certs formed chains intended to maximize the amount of crypto 
> processing the client does, before realizing that the chain is bad.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Apr 2004 11:40:44 -0400

>spoofed responses has a more obvious way to deny service ...

	remember, the example I gave has the property that it burns 
cycles on the client computer, irrespective of consuming network 
bandwidth. also, since you mention pre-generated responses below (a 
favorite technical strategy for your company, if I recall), then 
there would be no basis for a challenge response scheme. thus whether 
the adversary has to intercept you request or not is not at all clear.

>50 ms onto every response (plus $20k for a FIPS HSM, if you're serious).

	- the pre-generation issue is what I bet is your major 
concern, consistent with you company's model for OCSP, and your 
should have been more up front about that in your first message

	- given the size of the certs being returned, often multiple 
certs, it is hard to get excited about the bandwidth devoted to 
carrying a signature

	- you keep mentioning the costs of a FIPS evaluated HSM, 
which is a red herring, since PKIX makes NO statements about the 
level of assurance for the crypto implementations required for any of 
our standards.

>increase costs for PKI deployments.

this is a better line of argument.

The old PKIX document on this topic was RFC 2559 (from 1999). It was 
replaced by an RFC that is NOT a PKIX document, and thus does not 
necessarily represent a PKIX view of what is or is not appropriate in 
this context.  2559 said that additional integrity services were not 
required for LDAP responses, although it did call for SSL use for CA 
access to an LDAP server, to prevent denial of service attacks that 
could result if CRLs or certs were replaced with bogus replicas.  So, 
that RFC acknowledges that if a client gets only bogus certs (because 
the LDAP entries are corrupted) we have a DoS problem, yet if did not 
require integrity on retrieval of certs and CRLs from the LDAP 
server.  We seemed to have been of two minds here :-)

RFC 3379 (2002) established requirements for DPD and said that 
authenticated  requests and responses MAY be required. So, that RFC 
does not mandate integrity and authenticity for these exchanges, and 
it explicitly allows for use of lower layer mechanisms to provide 
these services.

So, we could mandate that DPD servers support signed requests and 
responses, and allow local users and admins to choose whether to 
invoke the feature, or we make it an optional aspect of 
implementations.  I do worry that the latter approach will result in 
depriving clients of the option, due to the sort of marketplace 
pressures that became evident in our discussion of pre-generated OCSP 
responses.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Apr 2004 14:04:21 -0400

>may not be a circular problem, but will degrade performance

We are not the LDAP WG, so we don't make requirements for directory 
access, as I noted in my previous message.  (Our last foray into that 
area is a superceded RFC that had mixed feelings about DoS issues.)

I thought there was a clear need to configure clients with an ability 
to directly verify signatures for DPD and DPV servers. Otherwsie, as 
you note, a circular dependency can arise.

Steve