Subject: RE: DISCUSS: MUST reject in OCSPv1

From: "Ryan M. Hurst" <[email-masked]>
Date: Wed, 26 Nov 2003 14:05:32 -0800

I know this isn't a poll, but to be clear MSFT does not support the MUST
reject in v1, nor the creation of a v2 for the nonce reason alone.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Michael Myers
Sent: Wednesday, November 26, 2003 12:05 PM
To: [email-masked]
Cc: Carlisle Adams
Subject: DISCUSS: MUST reject in OCSPv1

Colleagues,

I recently proposed to the chairs and the AD the following
action plan with respect to nonces in OCSP.  They in turn remain
curious as to working group consensus on the subject with a
particular emphasis on objections.  I had hoped for an ad-hoc
quorum on this in Minneapolis but it never materialized due to
the absence of several key players.

So, once more into the breach.  Who would object and why to the
following action plan (silence WILL be taken as consent):

1.  Regarding v1, clarify per the minutes as
    2560 goes from Proposed to Draft.  The
    operative text of which is that clients
    MUST reject a response that fails to
    incorporate a client's nonce.

2.  Simultaneously, initiate action on a v2
    I-D that will in part address technical
    changes in syntax and processing rules
    related to the use of nonces.

This is not a poll.  It is a request for discussion.  I expect
little disagreement on the intent of the v2 action item. The
core issue on v1 is "MUST reject".

To initiate the v1 discussion, my opinions are as follows.

1.  Nonces were established in OCSP to enable
    client driven prevention of replay attacks.
    Failure to respect a client's nonce is a
    direct denial of a client's request for
    this security service.  A responder that
    does so is contributing to the very security
    risks the requestor is seeking to mitigate.

2.  While 2560 also enables use of pre-produced
    responses, nonces and pre-produced responses
    are by definition mutually exclusive.  This
    effect should be immediately obvious to even
    the most naive of implementors, else they have
    no business writing code against this standard.
    A competent level of technical proficiency
    in implementing secure protocols is assumed.

3.  The "breakage" poll indicates that an
    overwhelming majority of OCSP implementors
    possess this competency.  11 of 12 client-side
    implementors reported no breakage with
    "MUST reject" while 10 of 12 server-side
    implementors responded likewise.

4.  The two server-side breakage points occur
    as a consequence of their use of pre-produced
    responses in a context where they have no
    administrative control over clients' use of
    nonces.  This can be addressed in v2, but in
    a v1 context we have no choice but to clarify
    original intent as ratified by the breakage poll.
    This breakage could also be relieved by relay
    of OCSP requests.

5.  The absence of normative language providing a
    tutorial on the proper use of nonces in a
    security protocol SHOULD NOT be taken up by
    any participant in this WG as an excuse to
    refute sound security principles.  Active
    participants in the Security Area of the IETF
    should be able to assume of their peers a
    superior grasp of and respect for foundational
    principles.

Objections to the "MUST reject" clarification are sought on the
basis of sound security engineering principles rather than
artful readings of ancillary language that enable specious
excuse from adherence to these principles in order to justify
current business models.

We are setting standards that must survive the test of time.  We
are supposed to check our corporate identities at the door.  We
are supposed to be individual engineers chartered to improve
Internet security.  Let us do so and get this problem solved.

My thanks to you all in advance for your patience with the
length of this note.

Mike

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Thu, 27 Nov 2003 09:09:25 -0800

My opinion is still that the client should get the un-nonced response and then the client should throw it out.
 
If there is a preceived need for returning a response without a nonce return internalError.
 
Ryan

________________________________

From: Michael Myers [mailto:[email-masked]]
Sent: Thu 11/27/2003 9:09 AM
To: Ryan M. Hurst; Santosh Chokhani; [email-masked]
Subject: RE: DISCUSS: MUST reject in OCSPv1

The more important thing is what a caching server is required to send back in the event it can't respond to a nonce.
 
Mike

	-----Original Message-----
	From: Ryan M. Hurst [mailto:[email-masked]]
	Sent: Thursday, November 27, 2003 9:48 AM
	To: Michael Myers; Santosh Chokhani; [email-masked]
	Subject: RE: DISCUSS: MUST reject in OCSPv1

	I don't think its silly, the client is still protected from the replay if the server responds to a nonced request with a un-nonced one as the client can decide decide if he wanted the protection or needed it.
	 
	That may sound strange, but nonce has other implications that re-play protection; it also implies freshness since pre-produced responses can not have the right nonce in it.
	 
	I still am not sure anything new is needed, but if it is leveraging criticality is probably the right way to go as long as it will not break folks; if it would I would fall back to the extension approach.
	 
	Ryan

---

From: "Miguel Rodriguez" <[email-masked]>
Date: Thu, 27 Nov 2003 12:34:27 -0600

I think this is the best option. We definitely need a normative on how
nonces relate to pre-produced responses. Meanwhile the discussion must
go on.

Miguel A Rodriguez
SeguriDATA
Mexico

> Sent: Thursday, November 27, 2003 8:19 AM
> To: Florian Oelmaier; [email-masked]
> Maybe the best thing to do is to reset 2560 back to Proposed,
> drop in a simple little extension like the below or something
> similar, put in some amply unambiguous normative language that
> makes it abundantly clear how nonces relate to pre-produced
> responses (in particular nonceless responses to nonced requests
> are strictly verboten) call it v1 still and let the RFC cycle at
> Proposed for an additional six months.  I could live with that.
> I don't know however if the IESG would let us do that.  Maybe if
> we could all agree on that course of action and ask nicely . . .
> ?
> 
> Mike
> 
> 
> 
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of
> > Florian Oelmaier
> > Sent: Wednesday, November 26, 2003 6:33 PM
> > To: 'Michael Myers'; [email-masked]
> > > I've chosen not to incorporate your well reasoned argument
> > > due to my business model.  :)
> >
> > hehehehe
> >
> > > How about in v1 we clarify by saying that "clients claiming
> > > conformance to this standard SHALL be capable of
> > rejecting . . . "
> >
> > What about something like:
> >
> > ------
> >
> > Clients including a nonce into the request MUST NOT
> > accept nonce-less
> > responses from responders that are known to be
> > capable of generating
> > nonces. If this is unknown for a certain responder,
> > clients MAY accept
> > the additional risk of accepting the nonce-less response.
> >
> > A responder MAY include the OCSPNonceSupported
> > extension into every
> > response to indicate the capability of producing
> > nonces to the client
> > (even in the case of a replay attack). The
> > OCSPNonceSupported extension
> > will be identified by the object identifier
> > id-pkix-ocsp-noncesupported,
> > while the extnValue is a boolean value indicating if
> > nonces are
> > supported by this responder (TRUE) or not (FALSE).
> >
> > id-pkix-ocsp-noncesupported     OBJECT IDENTIFIER ::=
> > { id-pkix-ocsp 8 }
> >
> > ------
> >

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Thu, 27 Nov 2003 14:21:12 -0800

I do not support this change for all the reasons called out previously.
 
Ryan

From: [email-masked] on behalf of Michael Myers
Sent: Thu 11/27/2003 12:31 PM
To: [email-masked]
Subject: RE: DISCUSS: MUST reject in OCSPv1

If anyone objects to the path forward as discussed below, please
speak up now.  Concurrence is equally welcome.

Mike

> David Engberg
> Sent: Thursday, November 27, 2003 12:46 PM
> To: Michael Myers
> Cc: [email-masked]
> Subject: Re: DISCUSS: MUST reject in OCSPv1
>
>
>
>
> Exactly.  I'd implement this right now if I wasn't so
> full of turkey.
>
>
> Michael Myers wrote:
> >
> > Understand your caching servers MUST send back a caveated
> > response which by presence of the caveat may or may not be
> > accepted.  No fair sending back plain ones, errors
> > notwithstanding.  Is this understood?
> >
> > Mike
> >
> >
> >>From: David Engberg [mailto:[email-masked]]
> >>Sent: Thursday, November 27, 2003 12:25 PM
> >>To: Michael Myers
> >>Cc: [email-masked]
> >>Subject: Re: DISCUSS: MUST reject in OCSPv1
> >>
> >>
> >>
> >>I'd add "or return an error [e.g. unauthorized?]" to
> >>the end of '4' (to
> >>remain compliant in the presence of requests for
> >>unknown certs), but it
> >>is otherwise my dream scenario.
> >>
> >>
> >>Michael Myers wrote:
> >>
> >>>Dave,
> >>>
> >>>So how about:
> >>>
> >>>1. If we can cycle v1 at Proposed (a big if); then
> >>>
> >>>2. Define nonceUnsupported extension subject to
> >>>   the following semantics (I'm squeezing the
> >>>   words a bit but you'll get the drift)
> >>>
> >>>3. Clients that send a nonce:
> >>>
> >>>   a. MUST reject a non-nonced response
> >>>      if that response includes either the
> >>>      value "good" or "revoked" AND it fails
> >>>      to include the nonceUnsupported extension;
> >>>
> >>>   b. Else, if such response includes the
> >>>      nonceUnsupported extension, clients
> >>>      MAY accept the response subject to the
> >>>      advice in the Security Considerations
> >>>      section of this document.
> >>>
> >>>4. Conversely, if a server receives a nonced
> >>>   request but is unable to incorporate the
> >>>   nonce in its response, the server MUST
> >>>   include the nonceUnsupported extension.
> >>>
> >>> Note that I made no distinction between "good",
> >>> "revoked" or "unknown" in #3.b or #4.  Thus,
> >>> a plain nonceless response of "good" or
> >>> "revoked" is non-conformant, while a caveated
> >>> response is subject to the client's local
> >>> security policy.
> >>>
> >>> Does this seem a fair compromise?  Note well it's highly
> >>> dependent on cycling v1 at Proposed.
> >>>
> >>> Mike
> >
> >
> >
>

---

From: "Florian Oelmaier" <[email-masked]>
Date: 28 Nov 2003 09:00:09 -0000

> If the client puts a nonce in a request and doesn't behave differently 
> depending on the presence/absence of the nonce in the response, then why 
> put the nonce in at all?

I agree. But the client behaves differently! It may
- display a warning to the user
- apply another local policy regarding time checking
- add additional measures to ensure freshness if a nonce is not present
- etc.

-- 
Florian Oelmaier
SyTrust

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Wed, 26 Nov 2003 14:05:32 -0800

Ryan

-----Original Message-----

Colleagues,

Mike