Subject: RE: Signing Untrusted SCVP?

From: "Dave Engberg" <[email-masked]>
Date: Mon, 5 Apr 2004 16:18:18 -0400

Stephen -

Sorry, I wasn't clear enough on pregeneration.  In the current draft,
the combination of a mandatory signature (or MAC) plus the mandatory
RequestReference inclusion in every response means that you can never
provide SCVP DPD without using a protected online key for each
transaction.  No caching (e.g.
http://www.rfc-editor.org/internet-drafts/draft-deacon-lightweight-ocsp-
profile-00.txt, section 4.2), no pregeneration, no keyless DPD servers.

My preference would be support for keyless DPD through optional
signatures, but pregeneration with a keyless HTTP caching tier would be
an unpleasant second option that would require that the RequestReference
be made optional.  Without at least one of these options, I'm
pessimistic about SCVP's usability for the sort of big (e.g.
governmental, inter-banking) PKIs that my company works with.

My reference to DPV security is well summarized in section 10 of the
SCVP spec:

   A client that trusts a server's response for validation of a 
   certificate inherently trusts that server as much as it would trust 
   its own validation software.  This means that if an attacker 
   compromises a trusted SCVP server, the attacker can change the 
   validation processing for every client that relies on that server.  
   Thus, an SCVP server must be protected at least as well as the 
   trust anchors that the SCVP server trusts.

In a serious PKI, most trust anchors are highly secured offline roots
with armed guards and missile launchers and whatnot.  I'm nervous about
trying to secure online DPV servers "at least as well as" PKI trust
anchors, and then service millions of requests a day from them over
public networks.  Server compromise (network or physical) of an
explicitly-trusted DPV server would be a very bad thing until you catch
it and reconfigure every relying client.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, April 05, 2004 1:58 PM
To: Dave Engberg
Cc: [email-masked]
Subject: RE: Signing Untrusted SCVP?

At 12:17 PM -0400 4/5/04, Dave Engberg wrote:

...

>I actually have a strong preference
>AGAINST pre-signing (or any kind of signing) for DPD responses, which 
>is the opposite of CoreStreet's preferred approach to OCSP.

I'm surprised by that assertion, given your comment in the previous
message that pre-signed responses were a problem if we require signed,
nonced (pardon the neologism) responses for DVD. if you are not a fan of
pre-signed responses, I would not have expected you to cite that
concern, nor raise the related issue of the cost of an expensive crypto
module. But, I'll take your word that these arguments, which seem to be
motivated by a preference for pre-signing, are not really representative
of your personal views.

...

>To be less
>circumspect about my motives:  I am interested in DPD and DPV, but 
>believe that SCVP DPV is a gigantic step backward for PKI security,

What parts of the rationale in 3379 for DPV do you not believe are true?

---

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Apr 2004 17:00:50 -0400

>profile-00.txt, section 4.2), no pregeneration, no keyless DPD servers.

There is a difference between pre-generated OCSP responses and 
reliance on a lower level security protocol to provide integrity for 
queries and responses. But, you are right that the latter still 
requires a key in the server to authenticate it to clients.

>governmental, inter-banking) PKIs that my company works with.

I'm not sure I have a preference, not having though about it in as much detail.

>it and reconfigure every relying client.

first, the argument about well protected trust anchors is not only a 
bit hyperbolic, but it is also backwards, since a TA is defined as a 
public key and associated parameters, not a private key.

Anyway, we should be more precise in analyzing the two approaches. 
for example, the private keys that are maintained offline and are 
very well protected, are not used except as a compromise recovery 
mechanism. the keys can't be both offline and used for day to day 
issuance of certs and CRLs. rather the common mode of use entails a 
second tier of CAs that are used daily, and thus are not offline. 
these keys should be well protected and that's where the expensive 
FIPS-evaluated (gee, I hope you get better than level 2 for $20K, we 
used to sell our level 3 device for less than that!) crypto module 
comes into play. for cert & CRL signing the centralization of the CA 
function does not pose a problem, so one need not spend a lot on high 
quality crypto modules, since they are not being widely distributed.

the problem arose when we adopted OCSP, because now there was a 
notion of an online server that had a much higher transaction rate, 
and the compromise of the private key was almost as bad as compromise 
of the key used to sign CRLs (not certs). it is not literally as bad, 
because if one has a small population of users that access a given 
OCSP server, then the number of folks affected by a compromise of 
that one sever is correspondingly small. On the other hand, that 
local server is the authoritative revocation status source for ALL 
CAs, for its client population, so the impact of a local compromise 
is different.

But how bnad is it to deal with a compromise of an OCSP server's key? 
One might   have a set of OCSP servers whose certs are issued by an 
offline CA, and the CRL for this set is issued by the same CA. then 
if there is a compromise of a server's key, one can revoke the 
server's cert, issue a new one, and notify clients via a CRL. that 
CRL, if limited to just OCSP servers, should not grow too big and 
thus its distribution and caching is not onerous. this hybrid scheme 
would help mitigate the risks associated with having keys in OCSP 
servers. The residual problem for live responses is performance, not 
security.

Still, I think we agree that DPV, like OCSP, is most appropriate for 
enterprise customers, not as a public service. the impact of 
compromise is less severe and ability to recover from compromise is 
better when the scope is limited. one has to balance the ability of 
an enterprise security admin to configuration manage lots of 
workstations and servers, vs. the ability to secure a few DPV 
servers. we have a lot of experience that suggests the configuration 
management task is hard and that admins usually fail. firewalls are 
attractive because they allow admins to focus efforts on a few, 
centrally managed resources that the admins control.

there is a lesson here.

Steve

---

From: "Ambarish Malpani" <[email-masked]>
Date: Mon, 5 Apr 2004 18:17:20 -0700

Hi Dave,
    I don't thing speed of signing is a legitimate concern these
days. If folks want to deploy a DPD server without needing to
worry about key security, they can always use 512 bit software
keys for their RSA operations.

I can generate over 1000 512 bit RSA signatures on my laptop. I am
sure the other work that the SCVP server will do in path creation
will overwhelm the work done for the signing.

A

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dave Engberg
> Sent: Monday, April 05, 2004 1:18 PM
> To: Stephen Kent
> Cc: [email-masked]
> Sorry, I wasn't clear enough on pregeneration.  In the 
> current draft, the combination of a mandatory signature (or 
> MAC) plus the mandatory RequestReference inclusion in every 
> response means that you can never provide SCVP DPD without 
> using a protected online key for each transaction.  No caching (e.g.
> My preference would be support for keyless DPD through 
> optional signatures, but pregeneration with a keyless HTTP 
> caching tier would be an unpleasant second option that would 
> require that the RequestReference be made optional.  Without 
> at least one of these options, I'm pessimistic about SCVP's 
> usability for the sort of big (e.g. governmental, 
> inter-banking) PKIs that my company works with.
> 
> My reference to DPV security is well summarized in section 10 
> of the SCVP spec:
> 
> In a serious PKI, most trust anchors are highly secured 
> offline roots with armed guards and missile launchers and 
> whatnot.  I'm nervous about trying to secure online DPV 
> servers "at least as well as" PKI trust anchors, and then 
> service millions of requests a day from them over public 
> networks.  Server compromise (network or physical) of an 
> explicitly-trusted DPV server would be a very bad thing until 
> you catch it and reconfigure every relying client.
> 
> 
> 
> I'm surprised by that assertion, given your comment in the 
> previous message that pre-signed responses were a problem if 
> we require signed, nonced (pardon the neologism) responses 
> for DVD. if you are not a fan of pre-signed responses, I 
> would not have expected you to cite that concern, nor raise 
> the related issue of the cost of an expensive crypto module. 
> But, I'll take your word that these arguments, which seem to 
> be motivated by a preference for pre-signing, are not really 
> representative of your personal views.
> 
> ...
> 
> >To be less

---

From: David Engberg <[email-masked]>
Date: Mon, 05 Apr 2004 22:07:17 -0400

Rather than assuming that SCVP DPD signatures must be mandatory and 
discussing low security ways of implementing them (no HSM, etc.), 
perhaps it would be useful to discuss what those signatures give you in 
a pure DPD response.

Unless I'm missing something, here's a full description of the only 
attack that is possible with unsigned pure DPD that is not possible with 
signed pure DPD:

In an environment with multiple SCVP servers in separate network 
locations, an attacker who can take complete control of the network link 
close to one of the servers could intercept SCVP requests and then 
provide syntactically correct (but unsigned) SCVP responses to clients 
to indicate that the server is unable to find a usable path that meets 
the client requirements.  A client with alternate SCVP server URLs 
explicitly configured would have to try the other URLs in an unsigned 
environment to be sure that none of them have a path, whereas in a 
signed environment, the client could assume from the signature that no 
path is available without trying the alternate URLs.  This would 
potentially save a few extra HTTP requests for every "no path" response 
for this hypothetical multi-URL client.

Any variation on this scenario renders the signed vs. unsigned 
equivalent.  E.g.:

* If the attacker has control of the network closer to the client, or 
control in front of multiple servers, s/he could DoS all requests to any 
of the SCVP servers (HTTP 404 errors, etc.).

* If the attacker has control of the SCVP server, s/he could issue a 
signed response with the same "no path" content.

* If clients only have one server URL (i.e. only one local server, or 
all servers are balanced from one host name), then the result is 
equivalent (unsigned error from attacker, client is stuck).

This attack sounds so awkward, and the payoff is so minor, that I really 
don't see the point of managing and protecting keys at every DPD server 
just to prevent it.  If I were an attacker who wanted to DoS a cert 
discovery mechanism like Untrusted SCVP or non-SSL LDAP, I could come up 
with about 20 easier and more fruitful attacks.

Am I correct that this is the only reason to require mandatory 
signatures on DPD responses?

---

From: Stephen Kent <[email-masked]>
Date: Tue, 6 Apr 2004 17:11:09 -0400

David,

	<SNIP>
>signatures on DPD responses?

no, you are not.

You described a class of attacks, but not at all what I hand in mind.

an attacker can create a response without intercepting the query. the 
question is what the client with do with such a response, e.g., how 
much effort will the client expend before it determines that the 
response is not appropriate. there are options in SCVP that would 
make it harder for an attacker to do this, but since these are 
options, we can't be sure that they would be used. the difficulty in 
sending a bogus response is also dependent on the transport mechanism 
employed. HTTP is suggested as the like method, but e-mail is cited 
as well, and other transports might be used in the future.

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.

when the client decides (via some unspecified means) that the server 
is "bad" the client is left not knowing whether the bad response was 
from the indicated server, or from some bogus server, if we have no 
signature. what is the client supposed to do? if he elects to locally 
"hot list" the server, then in a few attempts, the attacker may be 
able to cause the client to decide that there are no viable servers 
available to him, i.e., he may give up. he may back off for an 
unspecified period.  (remember the chaos that resulted when 
VeriSign's CRL services were overwhelmed not long ago? many clients 
hung for a while, I was told.)

The hallmark of a good DoS attack is one in which the attacker emits 
as few bad packets as possible, and inflicts the greatest denial or 
degradation of service. use of signatures in responses (and 
preferably on requests) minimizes opportunities for such attacks.

Steve

---

From: David Engberg <[email-masked]>
Date: Tue, 06 Apr 2004 23:31:31 -0400

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 7 Apr 2004 08:32:21 -0400

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 -

Thanks

Stephen Kent wrote:
...
...

---

From: Stephen Kent <[email-masked]>
Date: Wed, 7 Apr 2004 10:32:05 -0400

>be forced to sign the response

I disagree with your first assertion, and thus, not surprisingly, the 
conclusion. I think signature support for client and server should be 
mandated, but local amdins can choose to not invoke the feature.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 7 Apr 2004 10:24:00 -0400

At 11:31 PM -0400 4/6/04, David Engberg wrote:
>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).

Your next paragraph admits the problem is not the 500ms wasted in 
verifying signatures that lead to a dead end, but rather the errors 
that effectively kill the process and result in user error messages 
that deny service. So, I wonder why you chose to lead off with this 
red herring?

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

If the attacker cannot forge signatures on DPD server responses, then 
the DPD software will not be so easily led into error states based on 
the assumption that it is talking with a valid server. Thus reduces 
the opportunities for attackers to steer the user into a state of 
confusion. If one believed the argument you cite above, then we ought 
to not bother with checksums on TCP packets (which is often the 
slowest part of TCP processing), because the users will eventually 
figure out if a transmission was corrupted, and there are so many 
other ways that an attacker could deny a user service.

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

I don't know, and I don't care. It is a bad strategy to rely on past 
attack behavior as a primary predictor of future attacks.

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

I think it could be reasonable to give local admins that option, 
which requires that products support signatures and allow local 
admins to decide whether to employ the signatures.

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

Your Akamai example is a poor one; it says nothing about the need to 
secure keys at every server. And, by the way, every one of those 
severs does have a key in it, for use with Kerberos for managing the 
servers.

Steve