Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)

From: "Michael Myers" <[email-masked]>
Date: Wed, 19 Nov 2003 14:09:41 -0800

> -----Original Message-----
> From: David Engberg [mailto:[email-masked]]
> Sent: Wednesday, November 19, 2003 12:57 PM
>
> My preference would be a slight variant on Mike's #2:
> send back a  non-nonced response with a response
> extension indicating "nonceUnsupported".
>
> I think Mike's analysis for #2 is incomplete.  The
> original concensus was around the current behavior
> of clients in absence of this extension.

Dave,

Earlier today Steve wrote:  "I believe Russ's statement sets the
parameters for how we clarify this issue within the bounds of
OCSP v1."  Thus we need to determine, in part and if possible,
what a v1-based caching server MUST send back to a nonced
request using only the ASN.1 syntax defined by RFC 2560 as
written.  Your proposed nonceUnsupported, while a candidate for
v2 consideration, is clearly not within that v1 scope.

In v2, should it come to pass, we will no doubt entertain
ourselves to the point of exhaustion with all the proposals
currently on the table.  But in a v1 only context, we have four
options for an IETF standard governing OCSP caching server
action in the presence of a nonced request:  1) sever goes
silent; 2)ignore the nonce and send a non-nonced response
anyway; 3)send anything other than "good" or "revoked" as
selected from 2560's existing syntax; or 4) the WG does nothing
and lets the market sort it out.

v1 only, no new extensions.  How MUST a v1 caching server
respond to a nonced request?  Given the constrained solution
space, I prefer #3 using a non-nonced yet signed response value
of "unknown".

Mike

---

From: "Florian Oelmaier" <[email-masked]>
Date: 21 Nov 2003 11:15:50 -0000

> I'm not surprised at your result.  Server-unilateral nonces are
> arguably consistent with standing 2560 syntax. However, this
> practice is not identified in the standard.  

/agree. Please note that if you dont like that, you have to clarfiy that, too! But as I stated in a former message, I would prefer an explicit extension as proposed by David or Tom.

But my comment regarding extensions was not targeted towards server-generated nonces. While OpenValidation.org uses server-generated nonces, most (98%+) requests we get contain nonces. Please mind: this does not mean that the client would not accept a non-nonced answer, as most clients out there do not know if openvalidation.org does caching or not. 

In my comment I was speaking about another extension (a private extension used by OpenValidation.org to deliver additional information to the clients). This is ongoing work, the idea is to deliver additional background information about the CA that can be presented to the user.

In the end I just wanted to stress the fact that adding a new responseExtension in a separate RfC does not necessarily mean we need to increment the OCSP-version number. But I think we all agree on that.

> More importantly,
> is it not responsive to client-driven prevention of replay
> attacks.

I think it is. As the responder never signs a response without nonce, it is semantically the same as a "NonceSupported=true" Extension. This method  reliably protects clients sending "nonced" requests but accepting "non-nonced" responses.

But either way: as stated above, I would prefer the proposal of Tom or David.  So no need to discuss the server-generated nonce proposal any further - at least not from my side.

> As to the likelihood of clarifying 2560 as it goes from Proposed
> to Draft with the guidance provided us by our Area Director, see
> RFC 2026.  The "MUST reject" clarification is amply supported by
> the breakage poll.
> 
> If you disagree with Russ's guidance, take it up with Steve or
> Russ.

I think both follow the discussion here. I am here to give my point of view - at the end of the day it is not my decision what to put into the standard. And as for the poll I agree with several others here that if you would ask now, clearly worded and with all implications on the table, the result may be different. 

If the proposed change really goes through I will add an option to my client where the users can decide between three settings:

#1 standard compliance with normal security (works with all responders)

[Technically: will use requests without nonce ]

#2 standard compliance with high security (does not work with all responders)

[Technically: will use requests with nonce and will not accept responses without nonce]

#3 high security with some responders/normal security with most (works with all responders and improves security with some. While technically 100% compatible this is not compliant to the RfC!)

[Technically: will use requests with nonce but will accept responses without nonce. This is the former default behaviour of my client but as it will not be standard compliant anymore, I will warn the user explicitly that he leaves the holy ground with that decision. 
Additionally I have to introduce a second round-trip without nonce if I get an error message (as I may have got this error message due to missing nonce support by a caching responder). But I think most caching responders will include an "old version compatibility" mode and simply send back a non-nonced response to a nonced request. This is arguably consistent even with the changed RfC as extension processing is optional.]

I hope this clarifies why I am so unhappy with the outlined "decision". But I have not yet given up hope that I can change #3 to something like Toms extension proposal (NonceSupported):

#3 high security with new responders (normal security for all older responders, high security for all responders compliant to RfCxxxx)

[Technically: requests with nonce, will accept responses without nonce but will NOT accept responses without nonce if NonceSupported=True extension is set]

or Davids proposal (NonceUnsupported):
 
#3 high security with fallback (works with all responders except older caching responders)

[Technically: requests with nonce, will accept responses without nonce only if NonceUnsupported extension is present]

While also solving the problem, both alternatives are technically superior, easier to understand and more straightforward to implement. But this has been laid out several times now, maybe its time to let the matter rest here  and see what the market will do. 

-- 
Florian Oelmaier
SyTrust

---

From: Dave Engberg <[email-masked]>
Date: Fri, 21 Nov 2003 11:24:31 -0500 (EST)

Ok, we can accept that adding new extension declarations to v1 is 
out of scope.

Adding new mandatory rejection requirements (MUST) at the client and 
server based on the non-critical nonce extension does, however, prevent 
any willing v1-compatible clients and servers from choosing other security 
policies (e.g. based on other extensions) before v2.

Could we just change the new language from MUST to SHOULD for the client 
and the server?  This allows you to convey your intended semantics, but  
doesn't prevent the exploration of alternate security policies by willing 
client/server pairs before v2-final ...

Basically:  "Clients who send a nonce to a server and receive a response 
without a nonce SHOULD reject that response.  Servers who receive a 
request with a nonce who are unwilling or unable to supply a response with 
a nonce SHOULD return an 'unauthorized' error code."  (or somesuch)

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Fri, 21 Nov 2003 13:59:03 -0800

I agree this seems like a simple approach however the OCSP RFC
(http://ietf.org/rfc/rfc2560.txt?number=2560 ) states that extensions
SHOULD NOT be critical; the concern here is that using this scheme to
communicate this policy would be a violation of that statement and make
folks incompatible.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Marc Branchaud
Sent: Friday, November 21, 2003 11:35 AM
To: [email-masked]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)

Marc Branchaud wrote:
> 
> OTOH, if the client is willing to accept nonceless responses, it
simply 
> makes the request's nonce extension non-critical.

I also should've explicitly pointed out that it would be OK for a 
caching server to return a nonceless response in this case (i.e. to a 
request with a non-critical nonce).

		M.

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Mon, 24 Nov 2003 12:25:00 -0800

I suspect that many server implementations don't have appropriate
handling of critically marked extensions, even for known once like the
nonce due to the way the RFC is written.

That's not to say that if I am right their behavior would be correct,
but this is something we all experienced with the early days of X509
support.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Marc Branchaud
Sent: Monday, November 24, 2003 9:13 AM
To: [email-masked]
Subject: Re: OCSPv1 and nonces (RE: draft meeting minutes)

Ryan M. Hurst wrote:
> You are right, should not does mean not recomended however the likley 
> impact is that clients that do this will not be able to interoperate 
> with the existing servers out there.

They'll only be uninteroperable with servers that don't support nonces, 
which is exactly what we want.

The client would in any case be free to resend the query without the 
nonce, and the client could retain the fact that the server doesn't 
support nonces.

		M.