Subject: RE: Signing Untrusted SCVP?

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 7 Apr 2004 14:51:37 -0700

Hi Santosh,

I don't view the benefit as minimal. I see it as blocking some exploits
by attackers. Given we are now allowing cached values to be returned,
what is the concern? Are we trying to help the server or client?

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 12:34 PM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Trevor:

From technical philosophy viewpoint, I do not have a problem.

But, from my understanding of how IETF works, given that the benefit is
minimal, we need to define the standard that accommodates products with
varying degree of functionality.  I think SCVP requirement to sign DPD
responses may be too much.

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 2:07 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

Hi Santosh,
My argument cannot be construed as an argument to sign everything. It is
an
argument to sign all positive responses. I am equally not convinced that
no
singing achieves anything other than weaker security. The act of signing
is
not a major burden, especially if this is no longer on a per request
basis
and allows the client to be assured of positive. Not signing positive
responses allows an attacker to manipulate the client beyond inserting
errors which is very, very bad.

How the server protects the cache is an implementation decision.
Assuming
untrusted transport is reasonable for the RFC.

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 9:00 AM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

Trevor:

This argument can be the basis for signing everything all the time,
which we
do not do.

The attacker can still manipulate and inject data.  I am not persuaded
by
the argument that checking the signature first will save lot of client
processing time.

If the product developer and consumers want to have the option for not
signing this data, they should.

I see a bigger problem with the DPD server maintaining a cache and some
one
attacking that cache (if unsigned) since a stationary server may be
easier
to hack at then data in transit.  Now, if the DPD server signed cached
paths
on request or if the DPD, you have the same problem.

Also, my suggestion would be for the client to have the option of
requesting
signed responses and having the option of rejecting responses that are
not
signed.

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 11:46 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, April 07, 2004 5:32 AM
To: [email-masked]
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: [email-masked] [mailto:[email-masked]]
On
Behalf Of David Engberg
Sent: Tuesday, April 06, 2004 11:32 PM
To: Stephen Kent
Cc: [email-masked]
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.
...

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 8 Apr 2004 07:38:22 -0400

Trevor:

I would say more the server since the client can always ignore the signature
if it wishes and reject an unsigned response.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Trevor Freeman
Sent: Wednesday, April 07, 2004 5:52 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

Hi Santosh,

I don't view the benefit as minimal. I see it as blocking some exploits by
attackers. Given we are now allowing cached values to be returned, what is
the concern? Are we trying to help the server or client?

Trevor

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 2:07 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

Hi Santosh,
My argument cannot be construed as an argument to sign everything. It is an
argument to sign all positive responses. I am equally not convinced that no
singing achieves anything other than weaker security. The act of signing is
not a major burden, especially if this is no longer on a per request basis
and allows the client to be assured of positive. Not signing positive
responses allows an attacker to manipulate the client beyond inserting
errors which is very, very bad.

How the server protects the cache is an implementation decision. Assuming
untrusted transport is reasonable for the RFC.

Trevor

-----Original Message-----

Trevor:

This argument can be the basis for signing everything all the time, which we
do not do.

The attacker can still manipulate and inject data.  I am not persuaded by
the argument that checking the signature first will save lot of client
processing time.

I see a bigger problem with the DPD server maintaining a cache and some one
attacking that cache (if unsigned) since a stationary server may be easier
to hack at then data in transit.  Now, if the DPD server signed cached paths
on request or if the DPD, you have the same problem.

Also, my suggestion would be for the client to have the option of requesting
signed responses and having the option of rejecting responses that are not
signed.

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 11:46 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

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-----

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-----

Stephen -

Thanks

Stephen Kent wrote:
...
...