Re: [lamps] [EXTERNAL]Re: RFC6960: Issue with the OCSP Nonce extension

[Mike Ounsworth <[e-mail]>]

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 <[e-mail]> On Behalf Of Mohit Sahni
Sent: March 2, 2020 2:09 PM
To: Russ Housley <[e-mail]>; [e-mail]
Cc: [e-mail]
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:[e-mail]> 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:[e-mail]> 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/

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