Subject: RE: DISCUSS: MUST reject in OCSPv1

From: "Frank Balluffi" <[email-masked]>
Date: Mon, 1 Dec 2003 13:44:22 -0500

I agree with Ambarish.

Frank

"Ambarish Malpani" <[email-masked]>
Sent by: [email-masked]
11/28/2003 05:00 PM

        To:     "Florian Oelmaier" <[email-masked]>, "'Marc Branchaud'" 
<[email-masked]>, <[email-masked]>
        cc: 
        Subject:        RE: DISCUSS:  MUST  reject in OCSPv1

Hi Florian,
    The reason for including a nonce in the request is to enable a
client that doesn't have a very precise knowledge of time to still
be sure the response he got from the server was generated for this
specific request.

While I do agree with Mark and think that the "right" way would be
to require the client to require the nonce in the response, in the
interests of moving ahead, I vote to accept Mike's compromise
proposal that a client MUST require the nonce in the response
unless it is accompanied by a nonceUnsupported extension in
the response and the client is willing to accept a response w/o
a nonce. This preserves the semantics for current clients and
still allows caching servers to supply responses to clients
who will take them.

Regards,
Ambarish

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Florian Oelmaier
> Sent: Thursday, November 27, 2003 4:15 PM
> To: 'Marc Branchaud'; [email-masked]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> Your argument is "nonces are only for replay protection". Thats true.
> 
> Now lets discuss WHY a client wants to get replay protection. Seeing
> that we have the three times in the response with a clear semantic, the
> client is not harmed by a replay. So why should a client include a nonce
> into the request?
> 
> There are different reasons for that, but the main reason is: the client
> wants a "fresh" response. Following that path Ryans arguments apply as
> he presented it in his previous replies. A client will include a nonce
> into the request to ask for a "fresh" response. If the client does not
> need a fresh response, then replaying is not a problem (then it is a
> feature called "caching").
> 
> So if a responder gets a request with a nonce, it not only means "the
> client wants replay protection" - it also means "the client would like
> to get a fresh response". Because otherwise replay attacks would not
> matter.
> 
> -- 
> Florian Oelmaier
> SyTrust
> 
>

---

From: "Deacon, Alex" <[email-masked]>
Date: Mon, 1 Dec 2003 15:42:53 -0800

It looks like I've missed most of the fun, but here are my thoughts in
any case...

For the record, I would object to any v1 addition that would mandate a
"MUST reject" clause.

As for the nonceUnsupported proposal, it does have it merits.  However I
have to agree with Ryan by objecting to its standardization in v1 for
two reasons.  First, doing so will not allow for the "TLS Extension" use
case where OCSP responses are included in protocol exchanges.  Second,
it will make currently conformant clients, non-conformant.  I'm also
worried that such a large change to v1 now will break some
implementations.  

I'm happy to have discussions on these issue in the context of a v2
protocol.  But would suggest we leave v1 as it is.  

Alex

> From: Marc Branchaud [mailto:[email-masked]] 
> Sent: Friday, November 28, 2003 2:23 PM
> To: [email-masked]
> Subject: Re: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> Mike just gave me an offline whack to the head.
> 
> I have no objection to the original nonceUnsupported proposal, as 
> described in
> 	http://www.imc.org/ietf-pkix/mail-archive/msg07210.html
> including David's "return an error" addition in
> 	http://www.imc.org/ietf-pkix/mail-archive/msg07214.html
> 
> Having clarified my earlier clarification, I wish to reset the 
> conversation...
> 
> Florian: As we both support the proposal, we may be in danger 
> of violent 
> agreement.
> 
> Ryan: Your arguments have failed to convince me that the 
> proposal is bad.
> 
> Apologies to all for the churn.
> 
> 		M.
> 
> 
> Michael Myers wrote:
> > Marc,
> > 
> > The proposal is to cycle *v1* at Proposed to address this one issue.
> > We would also take the opportunity to clarify encoding of nonce
> > as OCTET STRING, which was going to happen anyway as v1 went
> > from
> > Proposed to Draft.
> > 
> > I take it then you have no objection to the core technical 
> aspects of 
> > the proposed resolution?
> > 
> > Mike
> > 
> > 
> >>[mailto:[email-masked]]On Behalf Of Marc Branchaud
> >>Sent: Friday, November 28, 2003 10:28 AM
> >>To: [email-masked]
> >>Subject: Re: DISCUSS: MUST reject in OCSPv1
> >>
> >>
> >>
> >>Michael Myers wrote:
> >>
> >>>Marc, your response was ambiguous.
> >>
> >>Just to clarify, then:
> >>
> >>The resolution started with a "big if": Cycling at
> >>proposed.  I have no
> >>objection to cycling at Proposed and issuing an
> >>OCSPv2 that works all
> >>this out.
> >>
> >>It's the "then" I am objecting to.  The proposed
> >>"then" is bad.
> >>
> >>		M.
> >>
> > 
> > 
>

---

From: "Deacon, Alex" <[email-masked]>
Date: Tue, 2 Dec 2003 11:33:15 -0800

But doesn't this ASN.1 additon make the interop issues with the existing
deployed client/server base even worse?  Its still not clear how we can
justify making such a large normative change to v1 at this point in the
process.  This spec has been at proposed for almost 4.5 years (!) now.

Alex

> From: Michael Myers [mailto:[email-masked]] 
> Sent: Tuesday, December 02, 2003 8:08 AM
> To: Russ Housley; [email-masked]
> > From: Russ Housley
> > Sent: Tuesday, December 02, 2003 6:42 AM
> >
> >
> >     OCSPNonce ::= CHOICE {
> >        nonceValue  OCTET STRING,
> >        unsupported  NULL }
> 
> Russ,
> 
> More precisely, based on the prior proposal, we have:
> 
> 1. Cycle v1 at Proposed with the above
>    amendment to nonce value syntax and
>    the following semantics.
> 
> 2. Clients that send a nonce:
> 
>    a. SHALL use the nonceValue CHOICE of
>       OCSPNonce value syntax.
> 
>    b. MUST reject a response that fails
>       to include the nonce extension
>       (errors notwithstanding);
> 
>    c. Else, if such response includes a
>       nonce extension with a value of
>       "unsupported", 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 a nonce extension with the value
>    "unsupported" for OCSPNonce.
> 
> So basically, it is pretty much the same semantics as 
> previously proposed, only using the "unsupported" CHOICE for 
> OCSPNonce as the caveat instead of an extension-based OID of 
> "unsupported".
> 
> Is this what you had in mind?  Note that we still have a 
> "MUST reject" for plain responses.
> 
> Mike
>

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 3 Dec 2003 08:45:38 +1000

If Russ's syntax will break compatibility and a new extension is deemed unnecessary, the functionality could be achieved by designating a specific nonce value as a "special" value to indicate that a server does not support nonces.  An empty octet string (04 00) would be a sensible candidate.

With this idea an extra restriction must be placed on servers that can use nonces so that they never issue a response with a empty octet string for the nonce, even if a (malicious) client included this nonce value in a request.  The fact that existing servers are unlikely to implement this rule would allow an attacker to make them appear to be caching-only servers.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Wednesday, 3 December 2003 12:42 AM
To: [email-masked]
Subject: RE: DISCUSS: MUST reject in OCSPv1

I am not very happy with the way that this discussion is going.  I am not 
convinced that a new extension is the best compromise.

...

    OCSPNonce ::= CHOICE {
       nonceValue  OCTET STRING,
       unsupported  NULL }

---

From: David Engberg <[email-masked]>
Date: Wed, 03 Dec 2003 23:05:30 -0500

I like the elegance of Russ and Florian's ideas for securely signalling 
that a server doesn't support nonces by using a special value for the 
nonce in replies.  This seems like the "right" place to put this message 
to the client.

We do have to keep in mind these approaches do still expose a replay 
potential when a "new" client that supports this system communicates 
with any "old" OCSP server that currently supports nonces.

Here's the attack:  Alice makes an OCSP request for her cert in the 
morning (when her cert is valid) with a nonce value of NULL (or whatever 
the special signalling value is).  All existing servers will return a 
response that includes this special value as the nonce, since they all 
just spit back the raw bytes of whatever nonce they receive.  Alice 
records the response.

In the afternoon, Bob makes a request to get the status of her cert, 
after she has been revoked.  Alice intercepts the request, replays the 
cached response, and Bob's new client thinks that the server is 
indicating that it doesn't support nonces, so he accepts the response 
anyway.

Sending the "nonce not supported" message from the server to the client 
through a separate new extension is a little more klunky, but it might 
be worth it to avoid any issues with backward compatibility.

---

From: "Florian Oelmaier" <[email-masked]>
Date: 4 Dec 2003 14:19:23 -0000

> Florian -
> 
> Sorry, my misunderstanding.  I think that your strategy is also good if 
> both the client and server implement it, but it sounds like your clients 
> would have the same backward-compatibility problem if talking to someone 
> else's old servers.  I.e. an attacker could send a nonceless request to 
> an old existing server and record the nonceless response, and then 
> replay that to your client to make you think that that server is 
> securely signalling that it doesn't support nonces.

/agree. Thats completely correct. 

The difference is that our strategy does not require new clients as it does not require anything "new" on the client side. But you are right, if a client talks to an "old" server the attack described is as feasible as with Russ´ proposal. Only "new" servers can prevent this type of attack in both proposals. My bad, sorry.

-- 
Florian Oelmaier
SyTrust

---

From: "Nystrom, Magnus" <[email-masked]>
Date: Thu, 4 Dec 2003 17:50:05 -0500 (Eastern Standard Time)

Russ wrote:

[...]

> Rather than defining a new extension, called nonceUnsupported, you have
> the opportunity to specify a syntax to go with this OID that does the
> same thing.  Something like:
>
>     OCSPNonce ::= CHOICE {
>        nonceValue  OCTET STRING,
>        unsupported  NULL }

Unfortunately, this would break compatibility with clients supporting RFC
3546 (see Section 3.6 in that document).

-- Magnus

---

From: "Florian Oelmaier" <[email-masked]>
Date: 5 Dec 2003 10:30:22 -0000

> I am concerned with the idea of making any change to the standard that
> "changes the 5 year old protocol".

I wholeheartly welcome the clarification and the change Russ proposed - but I am also concerned with interoperability issues.

Maybe we can keep the "old" nonce as it is and specify a new extension id for the new nonce? Then we can clarify that the "old" nonce is deprecated and that clients and servers should use the "new" nonce behaviour.

This way we can clarify the situation and simultaneous maintain compatibility.  

-- 
Florian Oelmaier
SyTrust

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Fri, 5 Dec 2003 14:10:45 -0800

Comments in line

-----Original Message-----
From: David Engberg [mailto:[email-masked]] 
Sent: Friday, December 05, 2003 12:01 PM
To: Ryan M. Hurst
Cc: [email-masked]; 'Florian Oelmaier'; [email-masked]
Subject: Re: DISCUSS: MUST reject in OCSPv1

The value of 'nonceUnsupported' is to allow a client to distinguish 
between 'a' and 'b' securely if that client cares about the difference 
between the two.  Without this mechanism, the client cannot securely 
tell the difference.

It sounds like the argument is that no client will/should ever care 
about this distinction.  This is an argument about "business case" 
rather than technology/security.
[rmh] I suppose so, I just don't see what the client would do with this
distinction; that's not to say there isn't something useful to be done
with it I just don't see it right now.

I believe that it would be valuable for many clients to make this 
distinction.  It allows a local security policy that permits 
interoperabitliy with certs (e.g. SSL certs) from all sorts of 
environments (e.g. with AIA fields).  I'd say clients would use this to 
implement a "use the security model that the server chooses" policy. 
 Not every client or user would choose this policy, but I believe some 
clients would do so if permitted.
[rmh] Is that useful? How is that any different than saying don't
require nonces from this server?

The presence of a 'nonceSupported' extension doesn't just permit replay,

it encourages it (i.e. caching). The 'nonceSupported' extension may also

indicate that that server is not vulnerable to key compromise or DoS 
attacks, and a client may choose to use that securely-transmitted 
information in its decision making.
[rmh] I see what you're trying to get across here, but there may be
other reasons a responder may not be able to include a nonce; for
example as a mater of configuration it is possible that a responder
still has a key but for performance it still only issues pre-generated
responses. 

Ryan M. Hurst wrote:

> comments in-line
------------------------------------------------------------------------
> *From:* David Engberg
> *Sent:* Fri 12/5/2003 11:17 AM
> *To:* Ryan M. Hurst
> *Cc:* [email-masked]; 'Florian Oelmaier'; [email-masked]
> *Subject:* Re: DISCUSS: MUST reject in OCSPv1
>
>Unfortunately, I think the anwer to Ryan's specific question is no.  If

>you send a nonce and get back a response without that nonce under the 
>current spec, you know either:
>
>   a)  The server does not support nonces
>   b)  An attacker is replaying a recorded response from a 
>nonce-supporting server
>  
>
>[rmh] This is absolutley true, but in either of these cases if the
client is attempting to protect against replay he would reject responses
in both a and b. And in not he wanted the "replay" (eg he wants caching
wherever he can get it)
>
>I think there needs to be another flag in the response (e.g. 
>nonceUnsupported extension) to securely separate 'a' from 'b'.
>[rmh] But what prevents the nonce unsupported response from being
replayed?
>
>Ryan M. Hurst wrote:
>
>>   1.
>>       What the responder returns if it can not return a nonce
>>   2.
>>       What the client must do when it receives a response to a nonced
>>       request
>>
>...
>
>> My take on #1 is that I don't see why the client needs to know that, 
>> after all if the response to a nonced request does not contain the 
>> same nonce doesn't that mean the server was unable to produce a
nonced 
>> response?

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Fri, 5 Dec 2003 14:27:22 -0800

Comments in-line

-----Original Message-----
From: Michael Myers [mailto:[email-masked]] 
Sent: Friday, December 05, 2003 12:52 PM
To: Ryan M. Hurst; David Engberg
Cc: [email-masked]; 'Florian Oelmaier'; [email-masked]
Subject: RE: DISCUSS: MUST reject in OCSPv1

> From: Ryan M. Hurst
> Sent: Friday, December 05, 2003 12:25 PM
>
> [rmh] But what prevents the nonce unsupported
>       response from being replayed?

While a caveated response can be replayed, it bears with it
unambiguous signed proof that the client's request for
anti-replay would not have been successful in the first place.

[rmh] Once again why does this matter, isn't that what you get by
getting the nonceless response back?

This is substantially different from replay of a nonceless
response captured from a server able and willing to support
nonces, but also able and willing to support non-nonced requests
(hence the capture and replay).
[rmh] But an attacker could just replay a response without this value,
how can this be relied upon?

In the former case, the replay protection is not there to begin
with and the server/service is being forthright about that.  Any
lawyer will tell you, full disclosure is good thing, especially
in the case when one has no contracted relationship with a
relying party.
[rmh] But if no client decision is being made off of this data, why
include it? Why break existing implementations?

In the latter case, anti-replay *is* available but the client is
being blocked from it by an attacker.  This is not so good.

Mike

---

From: "Deacon, Alex" <[email-masked]>
Date: Mon, 8 Dec 2003 09:17:45 -0800

Mike,

Clearly education and interop testing is a large part of the solution (and
one we have spent some time doing).

As for your blunt statement, the issue is when the non-normative statement
"The nonce cryptographically binds a request and a response to prevent
replay attacks." is read in the broader context of the normative statements
regarding extension support, things start to crumble. 

Alex

> Sent: Friday, December 05, 2003 5:22 PM
> To: Deacon, Alex; Ryan M. Hurst; [email-masked]
> Alex,
> Comments embedded below.
> > From: Deacon, Alex [mailto:[email-masked]]
> > Sent: Friday, December 05, 2003 4:59 PM
> > To: 'Michael Myers'; Ryan M. Hurst; [email-masked]
> > If I could be ensured that every OCSP client used to
> > hit ocsp.verisign.com would not include a nonce,
> > then I would have no problem with a MUST reject.
> 
> Well, that probably won't happen in the given target 
> environment.  But what you can do is tell them they shouldn't 
> while still providing them the full value of your OCSP 
> services. Given a sufficiently reliable clue, they probably 
> won't do so again.
> 
> > However because this environment receives requests
> > from a heterogeneous population of clients over
> > which we have no administrative control (to
> > paraphrase an earlier email of yours), there will
> > undoubtedly be cases where cert validation will
> > fail....not because the cert has been revoked, but
> > because the response does not include a nonce.
> 
> Not necessarily.  Be up front about it.  Tell them you don't 
> support nonces.  Let them decide IAW local security policy 
> whether to fail path validation process.  Give them a clue.
> 
> > I believe that clients should have the ability to
> > make up their own mind (local policy) in determining
> > if they should reject or accept such a response.
> 
> But to make that decision, they must be able to differentiate 
> between a server/service that chooses not to support nonces 
> and one that is willing to but which service is being blocked 
> by an attacker.
> 
> > A MUST reject would not allow for this or force a
> > client to not be compliant with the spec.
> 
> Apologies in advance for being so blunt about this, but 
> Section 4.4.1 of RFC 2560 opens with the sentence "The nonce 
> cryptographically binds a request and a response to prevent 
> replay attacks."  I remain curious how disregard of a 
> client's nonce nonetheless achieves this intended effect.  I 
> further note that RFC 3546 (TLS) defers to this precise 
> section regarding nonces.
> 
> 
> 
> 
>

---

From: "Deacon, Alex" <[email-masked]>
Date: Mon, 15 Dec 2003 09:56:04 -0800

Mike,

> Sent: Monday, December 15, 2003 9:54 AM
> To: Deacon, Alex; Tom Gindin
> Cc: [email-masked]
> > Sent: Monday, December 15, 2003 10:21 AM
> >
> > As I mentioned earlier, it will be important to
> > clarify this case as clients using piggybacked
> > OCSPResponses (such as those implementing the TLS
> > extension) may receive a response that contains a
> > nonce (the one the server generated) event though
> > they did not send one.
> 
> Alex,
> 
> To be clear, are you referring to server-unilateral nonces?

No.

> 
> Or to the fact that a TLS server may have in cache a nonced 
> response (retained as a consequence of a prior nonced 
> request) that it sends back in the TLS handshake even though 
> the TLS client did not supply a nonce in its embedded OCSP request?

Yes...this is what I was referring to.  

Alex