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

From: "Nystrom, Magnus" <[email-masked]>
Date: Wed, 19 Nov 2003 15:15:53 +0100 (W. Europe Standard Time)

James Manger wrote:

[...]
> P.S. Russ Housley's quote fails to accommodate an OCSP client that puts
> a nonce in an OCSP request because the client **prefers** to get replay
> protection, though may be willing to forgo that protection for the sake
> of a more scalable system if only cached responses are available.  It
> would be ok to add text saying "a client requiring replay detection can
> include a nonce in the request and reject a nonce-less response".

Exactly. Nonces are extensions, and 2560 says that its extension model is
"based on the extension model employed in X.509 version 3 certificates see
[RFC2459]. Support for all extensions is optional for both clients and
responders." As we know, the semantics for any non-critical extension is
"a non-critical extension MAY be ignored" [RFC3280].

Hence, as I see it, an OCSP responder is free to ignore any non-critical
OCSP extensions, including nonces, and yet be completely compliant. RFC
2560 does not say anything about the nonce extension being critical (in
fact, it recommends it to not be), and this is reflected in the behavior
of - currently conformant - OCSP responders. . It seems to me that if any
change is to be done on the responder side it would be better to state
that a responder which receives a request with a critical nonce extension
will have to provide a response back including that nonce or fail.

-- Magnus

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 19 Nov 2003 07:56:22 -0800

> -----Original Message-----
> From: Nystrom, Magnus
> Sent: Wednesday, November 19, 2003 6:16 AM
>
> . . .
>
> It seems to me that if any change is to be
> done on the responder side it would be better
> to state that a responder which receives a
> request with a critical nonce extension will
> have to provide a response back including that
> nonce or fail.

The core question is, how does the responder signal failure in a
way that enables closure of the protocol?

---

From: "Terry Hayes" <[email-masked]>
Date: Wed, 19 Nov 2003 10:42:40 -0800

I also diagree with the "decision" recorded in the minutes of the WG meeting.

The OCSP RFC clearly states that extensions are optional, and need not be processed by either the client or the responder.  This proposal makes a significant change in the standard by requiring special-case processing for the nonce extension.  This will cause existing implementations of responders to be non-conformant.

I do not believe that the current RFC is broken in any way.  It provides a method for a client to request a fresh OCSP response, and a method for checking that an appropriate response was generated.  This is the goal of this portion of the RFC, and it is satisfied by the existing extension and the existing processing requirements for extensions.  I agree that additional text that describes the processing by the client would make this clearer, but it seems to have been correctly interpreted by anyone that has implemented a client based on the current wording.

The current discussion seems to be motivated by an additional requirement that was not addressed in the original RFC.  This new requirement is to allow a client to accept a response that does not included a matching nonce, if the client can determine that the responder never includes nonces (such as a caching server).  There was an extension proposed on the list that would allow this requirment to be satisfied.  This new extension would be compatible with the current wording for extension processing in the OCSP RFC, and could be defined within the current OCSP v1 framework.

I think the concensus of the list was to leave the current RFC intact, and to work on defining an additional extension to handle the new requirement.

Terry Hayes

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 19 Nov 2003 12:21:24 -0800

Terry,

My comments embedded below largely revolve around what in your
opinion a *v1* caching server MUST send back in the event it
receives a nonced request but by system design is unable to
incorporate that nonce in a response.

There are four options for v1:

1. Go silent and send back nothing;

2. Send back a non-nonced response anyway;

3. Signal back anything other than a definitive
   "good" or "revoked",  where "anything other"
   must be selected from 2560 as it is written;

4. Or the IETF and this WG does nothing and lets
   the market decide.

Which of these v1 options do you prefer?  Extensions will lead
us to v2 and thus are excluded from the solution space.

I will tell you my opinion:

#1 opens the door to a needless sequence of retries
   that will lead PKI-using communities to further
   complain that PKI doesn't work.

#2 is in direct conflict with the "MUST reject"
   consensus.  It flies in the face of the sound
   security principles ratified by the initial
   poll and as reiterated by our Area Director in
   his guidance to the WG.

#3 could work if we could only agree on what
   that signal is with respect to running code.

#4 is only included for completeness, else why are
   we even bothering to debate the issue.

Mike

> From: Terry Hayes [mailto:[email-masked]]
> Sent: Wednesday, November 19, 2003 10:43 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: OCSPv1 and nonces (RE: draft meeting minutes)
>
>

We didn't decide so much as confirm the rough consensus of the
initial poll.  Clients MUST reject.

>
> The OCSP RFC clearly states that extensions are
> optional, and need not be processed by either the
> client or the responder.  This proposal makes a
> significant change in the standard by requiring
> special-case processing for the nonce extension.
> This will cause existing implementations of
> responders to be non-conformant.

The minutes do not propose an extension.  All is says is that
clients MUST reject.

> I do not believe that the current RFC is broken in
> any way.

Agree, it's not broken.  But it could use a little clarification
in this one area.

> It provides a method for a client to
> request a fresh OCSP response, and a method for
> checking that an appropriate response was generated.
> This is the goal of this portion of the RFC, and it
> is satisfied by the existing extension and the
> existing processing requirements for extensions.  I
> agree that additional text that describes the
> processing by the client would make this clearer, but
> it seems to have been correctly interpreted by anyone
> hat has implemented a client based on the current wording.

Strongly agree with your last point.

> The current discussion seems to be motivated by an
> additional requirement that was not addressed in the
> original RFC.  This new requirement is to allow a
> client to accept a response that does not included a
> matching nonce, if the client can determine that the
> responder never includes nonces (such as a caching
> server).

Yes, this is a new requirement, but perhaps better worded as
"nonce capability discovery".

> There was an extension proposed on the list
> that would allow this requirment to be satisfied.
> This new extension would be compatible with the
> current wording for extension processing in the OCSP
> RFC, and could be defined within the current OCSP v1
> framework.

Many ideas have been proposed and I'm sure we'll consider them
all in due course against a possible v2. Meanwhile there remains
this unresolved issue about what a v1 caching server MUST send
back to a nonced request.

> I think the concensus of the list was to leave the
> current RFC intact, and to work on defining an
> additional extension to handle the new requirement.

All this discussion clearly indicates a need to at least clarify
the intended semantics of the nonce extension and a strong
consensus via the {MUST reject, MUST incoporate} poll as to what
that clarification should say.

---

From: "Florian Oelmaier" <[email-masked]>
Date: Thu, 20 Nov 2003 01:29:36 +0100

Hello all,

you all know my position regarding this issue: I agree with Terry Hayes,
Miguel Rodriguez, James Manger, Magnus Nystrom, Ryan M.Hurst and all the
others argumenting along that line in the discussion a few weeks ago. 

I strongly believe that the first poll on this issue does not help us in
deciding this issue (as stated by Miguel).

THE PROBLEM is that some clients want to support both types of
responders: caching responders (or better cached responses) and "live"
responders without knowing what type of responder they are talking to
beforehand. To allow for a client-policy driven decision regarding
trustworthiness while simultaneous maintaining technical
interoperability these clients want to get nonces where possible but
will accept nonce-less responses, too (if the local policy is met:
timeout for freshness, confirmation of a warning dialog by the user,
etc.). 

THE STATUS QUO is that the clients described above can be tricked by an
attacker to accept replies without nonces from a responder that would
support nonces. This problem is not intrinsic to the system but could be
solved using the protocol. At least one solution (see 4) is already
applied in the market.

THE SOLUTIONS. After a lot of discussion on this list, we have a set of
proposed solutions. In my eyes, all of these solutions would solve the
problem described above. Allow me to try and summarize the options
presented:

1) Proposal of Russ Housely et al at IETF Meeting:
Clients MUST reject replies without nonces to requests with nonces.
Servers MUST reply with an error to requests with nonce if they are not
able to generate nonces.

2) Proposal of Tom Gindin
(http://www.imc.org/ietf-pkix/mail-archive/msg07000.html): 
All responders (especially those supporting nonces) should add a boolean
NonceSupported extension 

3) Proposal of David Engberg
(http://www.imc.org/ietf-pkix/mail-archive/msg06838.html): 
All responders not supporting nonces should add a NonceUnsupported
extension

4) Proposal of Florian Oelmaier
(http://www.imc.org/ietf-pkix/mail-archive/msg06766.html): 
All responders supporting nonces should add a server generated nonces to
the response if there is no nonce in the request

IN MY OPINION solution 1 is neither rough consesus in the WG nor based
on running code. With proposal 1 clients will loose a lot of
configuration flexibility and within some the default configuration will
break. With proposal 1 servers will loose a lot of configuration
flexibility and some installations will break. With proposal 1 the RfC
contradicts itself regarding OPTIONAL extension handling at the server. 
All other options are perfectly acceptable from my point of view. I like
the idea of adding an extension (proposal 2 or 3) as it is clearly
defined, easily understandable and due to the extension system
completely in line with all running code and with the wording of the
RfC.

MY OPINION is to leave OCSPv1 as it is and draft an additional RfC
providing the extensions needed. Eventually we should add a short link
pointing to this OCSP-extension-RfC into RfC2560.

-- 
Florian Oelmaier
SyTrust

PS: ADDITIONALLY within the discussion a second idea was floating
around: Upon receiving a request with nonce, a "caching" responder
eventually wants to forward the request to a "live" responder in the
background. To decide this, the responder would like to know if the
client would accept a response without nonce or not. While this is not a
security issue, it may be important in some environments. Seeing the
discussion above, this could be solved simultaneous. There are also some
proposals to solve this problem: 
- critical flag for nonces in the request
- WillAcceptNoncelessResponse extension
- WillNotAcceptNoncelessResponse extension

---

From: "Terry Hayes" <[email-masked]>
Date: Wed, 19 Nov 2003 17:03:32 -0800

> pointing to this OCSP-extension-RfC into RfC2560. 

I also believe that this is the correct approach.  Notice that the new extension(s)
most likely will work in the OCSP v1 framework.  There is no need to change
OCSP to v2, or wait for a OCSP v2 to define this extension.

Terry Hayes

---

From: "Terry Hayes" <[email-masked]>
Date: Wed, 19 Nov 2003 17:00:51 -0800

I prefer option 2.

A server that receives a request that includes an extension that it does not support should respond as
if that extension was not present in the request.  This is allowed by the processing rules for extensions.

A server that does not support the nonce extension should respond as if it was missing.  It should
send back a non-nonced response.

This position is not in conflict with the "client MUST reject" consensus.  It does conflict with the "MUST
incorporate" woding that has been proposed.  However I do not believe that there is any consensus on 
that part of the proposal.

Terry Hayes

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 20 Nov 2003 07:14:14 -0800

The version number will be updated since legacy clients that are
merrily going along parsing against v == 0 will very likely
choke when they see bits on the wire they weren't expecting.
One hopes today's clients will are today sufficiently robust in
their implementation, e.g.:

if( buf->v == 0 ) proceed( buf ) else fail( BADVERSION );

such that, upon receipt of a value for v other than 0 (i.e. v1),
they will fail( ) with grace rather than proceed( ) in good
faith and choke.

Given a version number roll, we would be remiss if we didn't
also take the time to consider other v2 issues unrelated to the
use of nonces.  This is all going to take some time.

Further, we're nowhere near ready to recommend to Steve and Tim
a technical resolution.  We haven't fully discussed all possible
options.  Among these is the option of including some type of
value in a responder's certificate that enables a priori client
side nonce capability discovery.

Meanwhile, 2560 is going from Proposed to Draft.  We are allowed
to and already have performed minor amendments.  The "MUST
reject" clarification will be another.

Mike

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Terry Hayes
> Sent: Wednesday, November 19, 2003 5:04 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: Marc Branchaud <[email-masked]>
Date: Fri, 21 Nov 2003 10:43:33 -0800

It seems to me that we could simply allow clients to make the nonce 
extension critical.

If the client makes nonce critical, it is essentially telling the server 
that it will not accept a nonceless (cached) response.

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

Responders that don't support nonces (e.g. caching or pre-generating 
responders) have to return an error (internalError?) if the request has 
a critical nonce extension.

This approach doesn't add any new MUSTs or SHOULDs.  It just gives 
clients the ability to ensure that their local policies are followed.

		M.

---

From: Marc Branchaud <[email-masked]>
Date: Fri, 21 Nov 2003 11:35:09 -0800

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