Subject: RE: Signing Untrusted SCVP?

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 7 Apr 2004 11:06:54 -0700

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: Wed, 7 Apr 2004 15:33:59 -0400

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

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

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 7 Apr 2004 13:13:49 -0700

I think we should just change the relevant MUSTs to "MUST be
capable of".

Mike

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 7 Apr 2004 16:48:11 -0400

Steve:

I agree.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2004 4:15 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

>responses may be too much.

This is a value judgement call. If one starts from the premise that 
the benefit is minimal, then the answer seems obvious. if one does 
not characterize the benefit that way, the answer is probably 
different.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 7 Apr 2004 16:15:25 -0400

Steve

---

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

I agree

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Michael Myers
Sent: Wednesday, April 07, 2004 4:14 PM
To: [email-masked]
Subject: RE: Signing Untrusted SCVP?

I think we should just change the relevant MUSTs to "MUST be capable of".

Mike

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 9 Apr 2004 17:42:33 -0700

Does anyone else agree or object?

Mike

-----Original Message-----
From: Santosh Chokhani
Sent: Thursday, April 08, 2004 4:40 AM

I agree

-----Original Message-----
From: Michael Myers
Sent: Wednesday, April 07, 2004 4:14 PM

Mike

---

From: David Engberg <[email-masked]>
Date: Sat, 10 Apr 2004 17:30:27 -0400

I could live with this (and so could my company), but my personal 
preference would be language changes which would also permit a customer 
to deploy SCVP servers which are only used for DPD and have no keys at 
all.  These servers would not be "capable of" signing responses, and no 
one would ever ask them to (or they would get an unsigned error if they 
did).  This would be the same as current PKIs that distributed certs and 
CRLs through LDAP directories that do not even have SSL keys.

I know there are dozens of options for implementing insecure software 
keys at every server, but by removing the keys entirely you avoid giving 
the incorrect impression that the servers should ever be "trusted" in 
the sense of DPV.  No client should be misconfigured to accept the 
signature of those servers as a replacement for its own local PKI 
validation.

---

From: "Michael Myers" <[email-masked]>
Date: Sat, 10 Apr 2004 15:24:18 -0700

My opinion is that as long as DPD-only servers are capable of
signing responses, I don't see a problem with such servers not
shipping with active key material.  They may not be
operationally capable nor deployed so but would be functionally
capable of compliance. The distinction is that a local security
administrator is able to activate DPD signing in response to
emerging threats without recourse to a vendor's software update.

Mike

-----Original Message-----
From: David Engberg [mailto:[email-masked]]
Sent: Saturday, April 10, 2004 2:30 PM
To: Michael Myers
Cc: [email-masked]
Subject: Re: Signing Untrusted SCVP?

I could live with this (and so could my company), but my
personal
preference would be language changes which would also permit a
customer
to deploy SCVP servers which are only used for DPD and have no
keys at
all.  These servers would not be "capable of" signing responses,
and no
one would ever ask them to (or they would get an unsigned error
if they
did).  This would be the same as current PKIs that distributed
certs and
CRLs through LDAP directories that do not even have SSL keys.

I know there are dozens of options for implementing insecure
software
keys at every server, but by removing the keys entirely you
avoid giving
the incorrect impression that the servers should ever be
"trusted" in
the sense of DPV.  No client should be misconfigured to accept
the
signature of those servers as a replacement for its own local
PKI
validation.