Subject: RE: OCSP response pre-production

From: "Florian Oelmaier" <[email-masked]>
Date: 2 Oct 2003 08:45:39 -0000

> As an alternative, pre-generated responses could include a flag or 
> extension in their signed body to indicate that not only are they not 
> supplying a nonce with this response, but that they don't supply nonces 
> with any response, and if you trust that responder (via its public key 
> cert), then you may choose to accept the non-nonce-bearing response from 
> that server with this explicit flag (if that is your policy).
> 
> This avoids the risk of someone replaying a response to you in which the 
> attacker chose not to supply a nonce, but you did.  It allows a client 
> to distinguish between a server saying "Here's a response without a 
> nonce because you I think you didn't ask for one" and "Here's a response 
> without a nonce because the responder for you or your CA does not use 
> nonces."
> 
> I believe the following is a valid security policy which some (most?) 
> clients may choose to implement as an option:
> 
>    - Send a nonce with every request
>    - Accept a response with a matching nonce from any trusted responder
>    - Accept a response with a nonceUnsupported extension from any
>        trusted responder
>    - Reject a response with no nonce and no nonceUnsupported extension
> 
> This would allow the client to be much more usable with random public 
> certs (using AIA fields and delegated responder certs) in real-world 
> settings like secure email, etc.
> 

I fully agree with this. It seems to be a good idea.

My idea of server-generated nonces is simply the other way round: If the responder wants to signal "nonceUnsupported", the response does not include a nonce, if the responder generally supports nonces it simply generates one for requests not containing one.

From my point of view both proposals do technically the same and are fine for me. Davids "nonceUnsupported"-extension is easier to understand and more clear while server generated nonces do not need changes in clients like Juliens or mine. I am fine with both - tell me when to begin implementing.

-- 
Florian Oelmaier
SyTrust

---

From: "Julien Stern" <[email-masked]>
Date: Thu, 2 Oct 2003 15:40:38 +0200

> From my point of view both proposals do technically the same and are fine for me. Davids "nonceUnsupported"-extension is easier to understand and more clear while server generated nonces do not nee…

I fully agree with this too. The server has to indicate whether it
supports nonces or not INSIDE the signed content. Server generated
nonces are a way, this extension is another (hmm, well, the equivalent
of server generated nonces would be an ICanProvideANonceIfYouWish
extension, but ...).
On this other hand, I think that it is dangerous to indicate this fact
as an _unsigned_ error, as this error reply could easily be faked by an
attacker, making him think a server does not support nonces while in
fact it does.

--
Julien

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 2 Oct 2003 08:50:05 -0700

If we don't define a nonce-specific error, it's predictable that
client developers will choose one of the existing 5 unsigned
error values in order to pop up a dialog that says, essentially,
"You used a nonce and received an error.  If you want to try
again not using nonces, click here."

It doesn't matter much which error; any one will do in order to
discover if nonce use is the problem.  In fact if nothing
changed I'm wondering what the server side *would* send back?
I've recently seen suggestions on this list for
malFormedRequest, internalError and unauthorized.

Not defining a nonce-specific error value escapes nothing.
Clients can today enable relying parties to achieve their
intended goals via error-triggered nonce capability discovery.

Mike

---

From: "Miguel Rodriguez" <[email-masked]>
Date: Thu, 2 Oct 2003 11:00:22 -0500

I agree with this too, the support for nonces should indicated in the
signed content, either as a special flag or as Julien suggested using
the nextUpdate field. I prefer any of these options over the definition
of a new (unsigned) error message.

Miguel A Rodriguez
SeguriDATA
Mexico

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Julien Stern
> Sent: Thursday, October 02, 2003 8:41 AM
> To: [email-masked]
> Subject: Re: OCSP response pre-production
> 
>

---

From: David Engberg <[email-masked]>
Date: Thu, 02 Oct 2003 12:41:06 -0400

If the only change is an error code in the unsigned portion of the 
protocol, there is no way for a client to automatically tell that the 
responder is intentionally configured to never send nonces.

This prevents a client from choosing this automatically-enforced 
security policy:

   Require nonce from servers that support nonces.
   Accept responses without nonces from trusted responders that
      securely indicate they won't ever provide a nonce.

Like you said, a solution based only around an unsigned error code would 
require explicit user acceptance for each responder, while the most 
users don't have the faintest idea what nonces (or OCSP for that matter) 
are.  The pop-up example you listed may as well be in Latin for the 
majority of users.

If nothing changes in the spec, caching-only servers will continue to 
send back a response without a nonce.  They won't send back any error 
because this is not an error under the current RFC.

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 2 Oct 2003 10:06:52 -0700

Dave,

I used the pop-up as an example.  It could very well be a
one-time configuration issue.   Or, as Jean-Marc Desperrier
suggested, all this hoo-hah could be a moot point when reduced
to practice.  In any case, specific software design features are
out of scope.

As you point out, caching servers today send back a non-nonced
response to a nonced request because 2560 is regrettably silent
on the point. 10 of 12 implementors seem to have understood the
principles of nonce use anyhow.  If that isn't rough consensus
and running code, I don't know what is.  Despite that, if this
WG, its chairs and our AD wish to condone the practice of
ignoring a nonce, I'd be happy to abide by that decision.

Mike

> From: David Engberg [mailto:[email-masked]]
> Sent: Thursday, October 02, 2003 9:41 AM
> To: Michael Myers
> Cc: [email-masked]

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 2 Oct 2003 11:34:37 -0700

Dave,

Even if we do nothing, means currently exist for clients to
discover if a server respects nonces via error signalling.  A
non-nonced response to a nonced request itself being an error in
perhaps then 11 of 12 client side implementions, including your
own.

All along I've been trying to avoid opening the pandora's box of
OCSPv2, but I guess it's time to do so.

The simple fix I most recently proposed could, I believe, be
applied to RFC 2560 as it progresses from Proposed to Draft due
to the poll's consensus.  Meanwhile, I strongly suspect that the
syntax and semantic changes of more sophisticated solutions will
force a version delta, a new I-D and all that entails regarding
WG, IETF and IESG ratification.  That is, OCSPv2.

We have a narrow window of opportunity to fix v1 as proposed and
so stem the tide of unilateral approaches to resolving its
current ambiguity regarding the use of nonces.  This way,
everybody's at least on the same page in the near term.

I propose we do so and in parallel move on to v2.  The v2
discussions will predictably lead us into latent issues not
associated with nonces.  As these things go, that will take a
while.

Do you agree to this course of action?

Mike

---

From: David Engberg <[email-masked]>
Date: Thu, 02 Oct 2003 15:22:31 -0400

If adding a new top-level error code is possible in v1, and adding a new 
response extension to indicate nonceUnsupported (or similar solution) is 
only possible in v2, then this may be the best course of action.

Thanks,
Dave

---

From: "Florian Oelmaier" <[email-masked]>
Date: Fri, 3 Oct 2003 03:18:03 +0200

> applied to RFC 2560 as it progresses from Proposed to Draft 
> due to the poll's consensus.  Meanwhile, I strongly suspect 
> that the syntax and semantic changes of more sophisticated 
> solutions will force a version delta, a new I-D and all that 
> entails regarding WG, IETF and IESG ratification.  That is, OCSPv2.

I am not a friend of adding an error message that adds nothing to the
security of the protocol but introduces the need for a second round-trip
into OCSPv1. As a client cannot really rely on the error message the
situation will not get better. From a security point of view, the
proposed error message does not bring any advantage (as it can be
faked), technically it introduces the disadvantage of having to do two
requests.

*** I therefore suggest to leave OCSPv1 as it is (instead of making it
worse) and work with Davids extension to go in for OCSPv2. ***

In the meantime (until we get OCSPv2) people can use server-generated
nonces (which are compliant with the current state of RfC2560 and with
all existing clients out there). 

-- 
Florian Oelmaier
SyTrust

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 2 Oct 2003 19:03:18 -0700

> From: Florian Oelmaier
> . . .
> I am not a friend of adding an error message that
> adds nothing to the security of the protocol but
> introduces the need for a second round-trip
> into OCSPv1. As a client cannot really rely on the
> error message the situation will not get better.
> From a security point of view, the proposed error
> message does not bring any advantage (as it can be
> faked), technically it introduces the disadvantage of
> having to do two requests.
>
> *** I therefore suggest to leave OCSPv1 as it is
> (instead of making it worse) and work with Davids
> extension to go in for OCSPv2. ***

Florian,

As I've been trying to explain, the capability for
error-triggered nonce discovery is already in place.  An
environment called to task by a security auditor for sending a
canned response to a nonced request, the latter which by
technical definition is an assertion by a relying party that the
RP does NOT wish to receive a canned response, can very easily
send back any unsigned error.  It's best if we at least
standardize one for interoperability if nothing else.

Mike

---

From: "Florian Oelmaier" <[email-masked]>
Date: Fri, 3 Oct 2003 13:13:56 +0200

Michael,

> [...] An 
> environment called to task by a security auditor for sending 
> a canned response to a nonced request, the latter which by 
> technical definition is an assertion by a relying party that 
> the RP does NOT wish to receive a canned response, can very 
> easily send back any unsigned error.  

I want to comment two points here:

1) the "technical definition" you give in the sentence above: "[sending]
a nonced request [is by] technical definition [an] assertion by a
relying party [client] that the RP [client] does NOT wish to receive a
canned [pre-produced/cached] response".

I think the discussion here on the list shows that your "technical
definition" is not common ground here. It is NOT what I think and it is
NOT what RfC2560 states. There is another definition supported by
RfC2560 and some people here on the list: "A client sending a nonce
expresses its wish to get a nonced response."

From my point of view this discussion showed:

A) your definition is not covered in RfC2560
B) there are multiple clients out there that make use of the benefits of
the definition as stated in RfC2560
C) there are multiple installations out there relying on these benefits

If you want to add such a change to the definition into the current
wording of RfC2560 one way or the other I think YOU are calling for
OCSPv2 - as this is a major change to some/many installations out there.

But I think thats the point where our discussion started :(

> [...] An 
> environment called to task by a security auditor for sending 
> a canned response to a nonced request, the latter which by 
> technical definition is an assertion by a relying party that 
> the RP does NOT wish to receive a canned response, can very 
> easily send back any unsigned error. It's best if we at least 

2) I am not against an additional error message, as long as its use is
OPTIONAL for the responder and the current behaviour of the responders
(sending a non-nonced response back) is allowed, too. We can readily go
for a wording like this, if you need this error response urgently:

"If a responder cannot process a nonce he SHALL indicate this by sending
an error status "NonceNotAllowed" or by sending a response without
nonce."

-- 
Florian Oelmaier
SyTrust