Subject: RE: Signing Untrusted SCVP?

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 7 Apr 2004 17:31:33 -0700

Hi Dave,
I think it is that bad. An attacker is giving you a response which is of
a content total their making which one would assume the client would
pass to its own chaining engine who then acts upon it. The simple act of
trying to validate the bag of carefully crafted certificates at the very
minimal send some unsuspecting client to the attacker web page. With a
signed response, if the client explicitly trust the signer, the attacker
can invalidate the signature or insert an error, but that is about it.
The client does not take the response at attempt some action upon it.
Trevor
-----Original Message-----
From: Dave Engberg [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 1:23 PM
To: Trevor Freeman; Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

I think that "very, very bad" might be a bit strong.  Steve pointed out
that an attacker could use unsigned responses to waste client CPU
resources before the client rejects an unsigned DPD response, and
possibly to lead a smart client to "hot list" the bad server.  Even with
signed responses, an attacker could achieve the same end result (or
worse) through all of the normal bad-guy means.  For example, spoofed
DNS could send clients to bad IP addresses (30 second timeout while MS
Outlook hangs ...) or servers that faked flaky TCP packets for infinite
exponential backoff, etc.

Steve's right that a signature might allow a very clever client to
mitigate a very specific type of time-wasting client DoS, but obviously
an attacker who can seize your networking or DNS can cause a DoS
regardless of whether the responses are signed.

"Very, very bad" would apply if an attacker could trick a non-buggy
client into accepting a cert for which there is no valid path.  This is
absolutly not possible with unsigned DPD lookups (or non-SSL LDAP),
although it definitely is a risk for "Trusted SCVP" if any server is
compromised.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Trevor Freeman
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.

---

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

I do see some benefit to the signature in light of the current ASN.1
vulnerability.  This will help the clients that have not applied the patch.

I have not done an analysis of the vulnerability to determine if the
attacker could manipulate the signed payload to exploit the ASN.1 bug in the
client.  I suspect so.

While LDAP is not PKIX, directory world will continue to be vulnerable to
that.

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

Hi Dave,
I think it is that bad. An attacker is giving you a response which is of a
content total their making which one would assume the client would pass to
its own chaining engine who then acts upon it. The simple act of trying to
validate the bag of carefully crafted certificates at the very minimal send
some unsuspecting client to the attacker web page. With a signed response,
if the client explicitly trust the signer, the attacker can invalidate the
signature or insert an error, but that is about it. The client does not take
the response at attempt some action upon it. Trevor -----Original
Message-----
From: Dave Engberg [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 1:23 PM
To: Trevor Freeman; Santosh Chokhani; [email-masked]
Subject: RE: Signing Untrusted SCVP?

I think that "very, very bad" might be a bit strong.  Steve pointed out that
an attacker could use unsigned responses to waste client CPU resources
before the client rejects an unsigned DPD response, and possibly to lead a
smart client to "hot list" the bad server.  Even with signed responses, an
attacker could achieve the same end result (or
worse) through all of the normal bad-guy means.  For example, spoofed DNS
could send clients to bad IP addresses (30 second timeout while MS Outlook
hangs ...) or servers that faked flaky TCP packets for infinite exponential
backoff, etc.

Steve's right that a signature might allow a very clever client to mitigate
a very specific type of time-wasting client DoS, but obviously an attacker
who can seize your networking or DNS can cause a DoS regardless of whether
the responses are signed.

"Very, very bad" would apply if an attacker could trick a non-buggy client
into accepting a cert for which there is no valid path.  This is absolutly
not possible with unsigned DPD lookups (or non-SSL LDAP), although it
definitely is a risk for "Trusted SCVP" if any server is compromised.

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

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.

---

From: David Engberg <[email-masked]>
Date: Thu, 08 Apr 2004 08:04:32 -0400

There are a large number of protocols (S/MIME, SSL/TLS) that send 
clients an unsigned bag of certificates for path discovery.  The reason 
some of us feel that the "garbage path" client attack is of minor impact 
is because:

* Effort is medium

* Payoff is low:  a few (or even a few dozen) RSA-2048 verifies on the 
client.  I don't believe any client will launch a web browser during a 
path validation attempt, particularly for manufactured certs that don't 
chain to a client's trusted root (since validation goes from the root down).

* The attack is immediately detected by the client as a major problem to 
be remedied

I agree that no client should ever be forced to receive unsigned DPD 
responses, and no server should ever be forced to send unsigned DPD 
responses, but if both the client and the server are willing, I argue 
that unsigned should be possible.