RE: Signing Untrusted SCVP?

["Trevor Freeman" <[e-mail]>]

I think there is significant value in signing the response from the SCVP
server. Given the main issue seems to be SCVP operating in an
environment where an attacker has the ability to inject packets going
between client and server into the data stream. Signing the response
relegates the attacker to injecting error packets - which is a low grade
DoS. Sending unsigned responses allows the attacker to inject a packed
as the server whatever they want as a genuine response, with
certificates  and content of there choosing. So we just turned every
SCVP client into a potential web beacon. Where the client has direct
trust in the server signing key this is a very secure process with DPD.
Trevor


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 5:32 AM
To: [e-mail]
Subject: RE: Signing Untrusted SCVP?


Given the limited value of signature, DPD response signature by the
server
should be optional and signature verification by the client should be
optional.

The question we should answer is that is there any benefit to adding an
option for the client to request a signature and then should the DPD
server
be forced to sign the response

(shades of OCSP nonce)

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On
Behalf Of David Engberg
Sent: Tuesday, April 06, 2004 11:32 PM
To: Stephen Kent
Cc: [e-mail]
Subject: Re: Signing Untrusted SCVP?




Stephen -

You have provided interesting techniques that an attacker could use to 
make a DPD client waste an extra 500ms verifying signatures before 
displaying a "bad path returned from server" dialog (or the equivalent).

That same attacker with the same advantages (DNS spoofing, etc.) could 
achieve the same effective denial of path discovery even if an extra 
signature is thrown on responses.  The attacker could obviously make 
clients waste time & bandwidth in lots of sneaky ways, although the 
relying application would ultimately report different error messages 
("unknown host: 'scvp.eubridge.org'", "connection timed out", "no route 
to host", "response signature verify failed", etc.).

I am curious whether the type of attack that you describe has ever been 
performed against a non-SSL LDAP directory in a manner that would not 
have been equally effective if SSL was in use.

While there is definitely a difference here, I think (hope?) that we 
agree that it may be useful for a PKI administrator to have the choice 
to deploy a path discovery mechanism which does not require a fresh 
signature from a protected server key for every request.  This would 
allow an administrator to balance the DoS risks for clients against the 
DoS risks for servers.

My guess is that virtually all real world DoS attacks exploit the 
centralized nature of secured servers, and the best cure for this is the

sort of distributed redundancy that a keyless or two-tier-caching DPD 
responder architecture would permit.  For example, Akamai has 16,000+ 
servers around the world with no SSL private keys.  They are subjected 
to daily DoS attempts (e.g. they host www.whitehouse.gov) which fail 
not due to the magic of PKI, but rather due to the redundancy you can 
build when you don't have to secure keys at every server.

Thanks


Stephen Kent wrote:
...
> if an attacker can spoof a DNS response, he can cause the client to 
> connect to him instead of the server, which would enable the bogus 
> server to receive the request as well as generate and send the 
> response, and in the absence of a signed response, the client cannot 
> know that he is not communicating with the intended server.
>
> a bogus server could then return bogus cert chains that fail to 
> validate, but which waste client resources. just how effective this 
> may be will be a function of client implementation details, which are 
> outside the scope of our standards.
...