Subject: [lamps] RFC6960: Issue with the OCSP Nonce extension

From: Mohit Sahni <[email-masked]>
Date: Mon, 2 Mar 2020 07:20:42 -0800

Hi All,
I started a thread about the issues with the OCSP Nonce extension which was
missing the maximum length for the Nonce field in the extension and could
create potential security issues with the OCSP responder following RFC
6960.
https://mailarchive.ietf.org/arch/msg/spasm/Nh9fD4smTXnF4mhNYmbcULfgBSA/

Based on valuable feedback that I got from the members here, I have written
a draft limiting the length of Nonce extension between 1-32 bytes.  Here is
the link to the draft
https://datatracker.ietf.org/doc/draft-msahni-lamps-ocsp-nonce/?include_text=1.
Please let me know what you think.

Thanks
Mohit Sahni

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 2 Mar 2020 07:45:15 -0800

Thanks for drafting this. Perhaps security considerations should mention
that the nonce should contain enough cryptographically strong randomness
to prevent easy guessing of the nonce (hence to fulfill the purpose)?

Regards,
Tomas

On 2020-03-02 07:20, Mohit Sahni wrote:
> Hi All,
> I started a thread about the issues with the OCSP Nonce extension
> which was missing the maximum length for the Nonce field in the
> extension and could create potential security issues with the OCSP
> responder following RFC 6960.
> Based on valuable feedback that I got from the members here, I have
> written a draft limiting the length of Nonce extension between 1-32
> bytes.  Here is the link to the
> draft https://datatracker.ietf.org/doc/draft-msahni-lamps-ocsp-nonce/?include_text=1.
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 2 Mar 2020 10:47:19 -0500

A nonce of 1 octet does not really provide the intended protection.  Maybe we more could be said in the Security Considerations about the minimum size.  Also, why is Section 3.1 indented?

Russ

> On Mar 2, 2020, at 10:20 AM, Mohit Sahni <[email-masked]> wrote:
> 
> Hi All,
> I started a thread about the issues with the OCSP Nonce extension which was missing the maximum length for the Nonce field in the extension and could create potential security issues with the OCSP responder following RFC 6960.
> https://mailarchive.ietf.org/arch/msg/spasm/Nh9fD4smTXnF4mhNYmbcULfgBSA/ <https://mailarchive.ietf.org/arch/msg/spasm/Nh9fD4smTXnF4mhNYmbcULfgBSA/>
> 
> Based on valuable feedback that I got from the members here, I have written a draft limiting the length of Nonce extension between 1-32 bytes.  Here is the link to the draft https://datatracker.ietf.org/doc/draft-msahni-lamps-ocsp-nonce/?include_text=1 <https://datatracker.ietf.org/doc/draft-msahni-lamps-ocsp-nonce/?include_text=1>. Please let me know what you think.
> 
> Thanks
> Mohit Sahni

---

From: Mohit Sahni <[email-masked]>
Date: Mon, 2 Mar 2020 12:08:38 -0800

@Thomas:
Using "cryptographically strong randomness" to generate nonce is a good
suggestion and I also thought about it while writing the draft. The purpose
of nonce in OCSP request/response is to detect a replay. As long as a
client receives the same nonce in response as what they sent in request and
the signature in OCSP response can be verified and trusted they should able
to detect a replay attack. In my opinion client should not reuse the same
nonce in multiple requests, we can either mandate client to use different
nonce for each request made in a specified window of time or we can mandate
client to use "cryptographically strong randomness" to get a random nonce.
Please suggest which approach is better in your opinion.

@Russ, sure, I am taking a note of adding security consideration about
"using 1 octet nonce".  Regarding the section 3.1, I added it to highlight
risks created by the recommendation made in RFC5019, which suggests that if
server does not send a nonce in OCSP response then client should not reject
the response just because nonce is missing(
https://tools.ietf.org/html/rfc5019#section-4). I know its out of context
here but still wanted to re-enforce that there is a risk of replay attack
if client chose to accept the response with the missing nonce.

Thanks
Mohit

On Mon, Mar 2, 2020 at 7:47 AM Russ Housley <[email-masked]> wrote:

> A nonce of 1 octet does not really provide the intended protection.  Maybe
> we more could be said in the Security Considerations about the minimum
> size.  Also, why is Section 3.1 indented?
>
> Russ
>
>
> which was missing the maximum length for the Nonce field in the extension
> and could create potential security issues with the OCSP responder
> following RFC 6960.
> written a draft limiting the length of Nonce extension between 1-32 bytes.
> Here is the link to the draft

---

From: Mike Ounsworth <[email-masked]>
Date: Mon, 2 Mar 2020 20:29:20 +0000

My two cents on “cryptographically strong randomness”: don’t you also need to consider an attack that replays somebody else’s OCSP response? So in addition to a client not reusing the same nonce in multiple requests, I think you also need to avoid having your nonce collide with nonces from other clients who are asking about the same certificate, right? A cryptographically random 16/32 byte nonce seems like the way to go.

---
Mike Ounsworth
Software Security Architect, Entrust Datacard

From: Spasm <[email-masked]> On Behalf Of Mohit Sahni
Sent: March 2, 2020 2:09 PM
To: Russ Housley <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: [EXTERNAL]Re: [lamps] RFC6960: Issue with the OCSP Nonce extension

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________________
@Thomas: 
Using "cryptographically strong randomness" to generate nonce is a good suggestion and I also thought about it while writing the draft. The purpose of nonce in OCSP request/response is to detect a replay. As long as a client receives the same nonce in response as what they sent in request and the signature in OCSP response can be verified and trusted they should able to detect a replay attack. In my opinion client should not reuse the same nonce in multiple requests, we can either mandate client to use different nonce for each request made in a specified window of time or we can mandate client to use "cryptographically strong randomness" to get a random nonce. Please suggest which approach is better in your opinion. 

@Russ, sure, I am taking a note of adding security consideration about "using 1 octet nonce".  Regarding the section 3.1, I added it to highlight risks created by the recommendation made in RFC5019, which suggests that if server does not send a nonce in OCSP response then client should not reject the response just because nonce is missing(https://tools.ietf.org/html/rfc5019#section-4). I know its out of context here but still wanted to re-enforce that there is a risk of replay attack if client chose to accept the response with the missing nonce.

Thanks
Mohit 

On Mon, Mar 2, 2020 at 7:47 AM Russ Housley <mailto:[email-masked]> wrote:
A nonce of 1 octet does not really provide the intended protection.  Maybe we more could be said in the Security Considerations about the minimum size.  Also, why is Section 3.1 indented?

Russ

On Mar 2, 2020, at 10:20 AM, Mohit Sahni <mailto:[email-masked]> wrote:

Hi All,

Based on valuable feedback that I got from the members here, I have written a draft limiting the length of Nonce extension between 1-32 bytes.  Here is the link to the draft https://datatracker.ietf.org/doc/draft-msahni-lamps-ocsp-nonce/?include_text=1. Please let me know what you think.

Thanks
Mohit Sahni

---

From: Mohit Sahni <[email-masked]>
Date: Mon, 2 Mar 2020 13:26:22 -0800

I agree to you regarding the nonce, collision and I will update the draft
with statement that clients SHOULD use “cryptographically strong
randomness” and it's more secure to have nonce to be between 16-32 octets
long.

-Mohit

On Mon, Mar 2, 2020 at 12:29 PM Mike Ounsworth <
[email-masked]> wrote:

> My two cents on “cryptographically strong randomness”: don’t you also need
> to consider an attack that replays somebody else’s OCSP response? So in
> addition to a client not reusing the same nonce in multiple requests, I
> think you also need to avoid having your nonce collide with nonces from
> other clients who are asking about the same certificate, right? A
> cryptographically random 16/32 byte nonce seems like the way to go.
>
> ---
> Mike Ounsworth

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 2 Mar 2020 13:30:48 -0800

Agreed. And never re-use a nonce, should be new, random, for every request.

Cheers,
Tomas

On 2020-03-02 13:26, Mohit Sahni wrote:
> I agree to you regarding the nonce, collision and I will update the
> draft with statement that clients SHOULD use “cryptographically strong
> randomness” and it's more secure to have nonce to be between 16-32
> octets long. 
> 
> -Mohit 
> 
> On Mon, Mar 2, 2020 at 12:29 PM Mike Ounsworth
> <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     My two cents on “cryptographically strong randomness”: don’t you
>     also need to consider an attack that replays somebody else’s OCSP
>     response? So in addition to a client not reusing the same nonce in
>     multiple requests, I think you also need to avoid having your nonce
>     collide with nonces from other clients who are asking about the same
>     certificate, right? A cryptographically random 16/32 byte nonce
>     seems like the way to go.
> 
>     ---
>     Mike Ounsworth
>     From: Spasm <[email-masked] <mailto:[email-masked]>>
>     On Behalf Of Mohit Sahni
>     To: Russ Housley <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>     Cc: [email-masked] <mailto:[email-masked]>
>     Using "cryptographically strong randomness" to generate nonce is a
>     good suggestion and I also thought about it while writing the draft.
>     The purpose of nonce in OCSP request/response is to detect a replay.
>     As long as a client receives the same nonce in response as what they
>     sent in request and the signature in OCSP response can be verified
>     and trusted they should able to detect a replay attack. In my
>     opinion client should not reuse the same nonce in multiple requests,
>     we can either mandate client to use different nonce for each request
>     made in a specified window of time or we can mandate client to use
>     "cryptographically strong randomness" to get a random nonce. Please
>     suggest which approach is better in your opinion. 
> 
>     @Russ, sure, I am taking a note of adding security consideration
>     about "using 1 octet nonce".  Regarding the section 3.1, I added it
>     to highlight risks created by the recommendation made in RFC5019,
>     which suggests that if server does not send a nonce in OCSP response
>     then client should not reject the response just because nonce is
>     missing(https://tools.ietf.org/html/rfc5019#section-4). I know its
>     out of context here but still wanted to re-enforce that there is a
>     risk of replay attack if client chose to accept the response with
>     the missing nonce.
> 
>     Thanks
>     Mohit 
> 
>     On Mon, Mar 2, 2020 at 7:47 AM Russ Housley
>     <mailto:[email-masked] <mailto:[email-masked]>> wrote:
>     A nonce of 1 octet does not really provide the intended protection. 
>     Maybe we more could be said in the Security Considerations about the
>     minimum size.  Also, why is Section 3.1 indented?
> 
>     Russ
> 
> 
> 
>     On Mar 2, 2020, at 10:20 AM, Mohit Sahni
>     <mailto:[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi All,

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 2 Mar 2020 21:33:19 +0000

Which is more important than cryptographically strong.  A one-byte value  can all too easily wrap.  A 32bit sequence number probably suffices.

On 3/2/20, 4:32 PM, "Tomas Gustavsson" <[email-masked]> wrote:

    Cheers,
    Tomas

---

From: Mohit Sahni <[email-masked]>
Date: Mon, 2 Mar 2020 13:48:54 -0800

Hi Rich,
Currently RFC 6960 defines the OCSP nonce in section 4.4.1 and it does not
mention anything about minimum and a maximum length on nonce. I proposed a
range for length as1-32 octets keeping in mind the backward compatibility.
There may be some older clients and responders which may be
sending/processing different lengths of nonce. Based on the feedback by
Thomas, I proposed an upper bound of 32 as its already working in a popular
PKI implementation and they have not seen any issues with that. Please see
this link for more background on this:
https://mailarchive.ietf.org/arch/msg/spasm/2aKuvO6YomMsxbuCv4lHq05Uaac/

I will add text to strongly suggest that a nonce length should be between
16-32 octets and make sure implementations know the risk of using smaller
size nonce.

Thanks
Mohit

On Mon, Mar 2, 2020 at 1:33 PM Salz, Rich <[email-masked]> wrote:

> Which is more important than cryptographically strong.  A one-byte value
> can all too easily wrap.  A 32bit sequence number probably suffices.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 2 Mar 2020 21:50:02 +0000

*   I will add text to strongly suggest that a nonce length should be between 16-32 octets and make sure implementations know the risk of using smaller size nonce.

That’s fine with me, thanks.

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 2 Mar 2020 13:58:34 -0800

As the Nonce is set by the client the server can not enforce a minimum
length. The server typically just copied the nonce from the request into
the response. Now it's also checking that the client does not send more
than 32 bytes as nonce and will give a Unauthorized response if the
nonce sent by the client is >32 bytes.

So, there is a client-server separation.
- minimal size is a recommendation for OCSP clients
- maximum size is a limit enforced by the OCSP responder

Cheers,
Tomas

On 2020-03-02 13:50, Salz, Rich wrote:
>   * I will add text to strongly suggest that a nonce length should be
>     between 16-32 octets and make sure implementations know the risk of
>     using smaller size nonce. 
> 
>  
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 2 Mar 2020 17:06:03 -0500

I think you mean a freshly generated random value.  You do not mean that an implementation should make sure that it has not previously used that particular value.

Russ

> On Mar 2, 2020, at 4:30 PM, Tomas Gustavsson <[email-masked]> wrote:
> 
>

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 2 Mar 2020 14:11:56 -0800

> I think you mean a freshly generated random value.  You do not mean that an implementation should make sure that it has not previously used that particular value.

Correct, that's what I mean.

---

From: Mike Ounsworth <[email-masked]>
Date: Mon, 2 Mar 2020 22:42:46 +0000

As I understand it, a client using a short or low-entropy nonce is opening themselves to replay attacks, but there is no risk to the server. That contrasts with too-long nonces - DoS and signature forgery attacks - where the risk is to the server.

An OCSP responder *could* enforce a minimum nonce length in the same way - by rejecting requests that don't conform - but maybe there is not a strong reason to because "the client is only hurting itself" ?

---
Mike Ounsworth | Office: +1 (613) 270-2873

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Tomas Gustavsson
Sent: March 2, 2020 3:59 PM
To: [email-masked]
Subject: Re: [lamps] [EXTERNAL]Re: RFC6960: Issue with the OCSP Nonce extension

As the Nonce is set by the client the server can not enforce a minimum length. The server typically just copied the nonce from the request into the response. Now it's also checking that the client does not send more than 32 bytes as nonce and will give a Unauthorized response if the nonce sent by the client is >32 bytes.

Cheers,
Tomas

---

From: Mohit Sahni <[email-masked]>
Date: Sun, 8 Mar 2020 14:29:55 -0700

Hi All,
I have upload a new version of the draft based on your valuable feedback.
Here are the main changes:
1. Added a section under security considerations about importance of using
a cryptographically  strong randomness that is freshly generated for the
nonce value and about the importance of using a Nonce of larger lengths to
avoid replays.
2. Modified the section 2.1 to explicitly mention that server should reject
a ocsp request with nonce of more than 32 bytes as malformedRequest error.
3. Added the following requirements in section 2.1
        a) The newer clients should use nonce of at-least 16 bytes and the
minimum length of 1 is specified only for the purpose of backward
compatibility with clients following RFC 6960.
         b) The Nonce MUST be generated using a cryptographically
strong pseudorandom number generator.

I hope I have taken care of all the comments, please review the new version
of draft at below mentioned URL and let me know any further feedback.
https://datatracker.ietf.org/doc/draft-msahni-lamps-ocsp-nonce/

Regards,
Mohit

On Mon, Mar 2, 2020 at 2:42 PM Mike Ounsworth <
[email-masked]> wrote:

> As I understand it, a client using a short or low-entropy nonce is opening
> themselves to replay attacks, but there is no risk to the server. That
> contrasts with too-long nonces - DoS and signature forgery attacks - where
> the risk is to the server.
>
> An OCSP responder *could* enforce a minimum nonce length in the same way -
> by rejecting requests that don't conform - but maybe there is not a strong
> reason to because "the client is only hurting itself" ?
>
> ---
> than 32 bytes as nonce and will give a Unauthorized response if the nonce
> sent by the client is >32 bytes.
>