Subject: Re: [lamps] AD Review of draft-ietf-lamps-ocsp-nonce-02

From: Mohit Sahni <[email-masked]>
Date: Sun, 2 Aug 2020 20:53:18 -0700

Hi Roman
Can you please review the snippets of the changes below to see if they
resolve your comments? If they look ok, then I will publish the new version
of the draft.

Thanks,
Mohit

On Sun, Jul 26, 2020 at 7:00 PM Roman Danyliw <[email-masked]> wrote:

> Hi!
>
> I conducted an AD review of draft-ietf-lamps-ocsp-nonce-02.  Thanks for
> the work on this document to harden the nonce extension of RFC 6960.  Below
> is my feedback:
>
> ** Section 2.  Editorial.  s/Following is the list/The following is a list/
>

   certificates (see [RFC5280]). The following is a list of standard
   extensions that can be used in the OCSP messages by the OCSP
   responder and OCSP client.

** Section 2.1.  This section appears to be a complete rewrite of the text
> in 4.4.1 of RFC6960 with the exception of the definitions of id-pkix-ocsp
> and id-pkix-ocsp-nonce.  To eliminate confusion, I would recommend you add
> these definitions here (id-pkix-ocsp and id-pkix-ocsp-nonce) and state that
> this new text replaces the entirety of Section 4.4.1.
>

   This section replaces the entirety of the Section 4.4.1 of [RFC6960]
   which describes the OCSP Nonce extension.
.
.
      id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp }
      id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

      Nonce ::= OCTET STRING(SIZE(1..32))

> ** Section 2.1.  Per "The minimum nonce length of 1 octet is defined to
> provide the backward compatibility with clients following [RFC6960].
> However the newer OCSP clients MUST use length of at least 16 octets for
> Nonce ...", how would this guidance work in practice from the perspective
> of the server?
> -- Is this saying that servers shouldn't reject 1 octet nonces for
> backward compatibility?
>
> -- How do I judge if I have a "newer OCSP client" if I have a server?
>

The minimum nonce length of 1 octet is defined to provide the backward
compatibility
   with older clients following [RFC6960] however, the newer OCSP
   clients MUST use a length of at least 16 octets for Nonce extension.
   The OCSP responder MAY choose to ignore Nonce extension for the
   requests where length of the Nonce extension is less than 16 octets.

>
> ** Section 3.1.  s/a man in the middle (MiTM) entity/an on-path attacker/
>

   request [RFC5019], an on-path attacker can intercept the OCSP request

> ** Section 3.1.  Per "This can be mitigated by the server using a closer
> nextUpdate value ...", as the units of nextUpdate are time what does
> "closer" mean?
>

   This can be mitigated by configuring the server to
   use a short time interval between thisUpdate and nextUpdate fields in
   the OCSP response......

> ** When is cryptographically strong PRNG needed?
>
> -- Section 2.1 seems to be restricting the "cryptographically strong
> pseudorandom number generator" to only new clients ("However the newer OCSP
> clients MUST use length of at least 16 octets for Nonce extension and the
> value of the nonce MUST be generated using a  cryptographically strong
> pseudorandom number generator")
>
> -- Section 3.2 seems to be saying something stronger that all client need
> strong randomness ("Therefore the client MUST use a nonce value that
> contains cryptographically strong randomness").
>
Updated section 2.1 and 3.2 to have the same intent. Please see the text
below:

>
> ** Section 3.2.  Per "A client SHOULD use 32 octets for nonce length", it
> was odd to me to specify a minimum length in Section 2.1, but the
> recommended length here.  Why not put the guidance in one place?
>

Section 2.1:
   The value of the nonce MUST be generated using a cryptographically
   strong pseudorandom number generator. The OCSP clients SHOULD use a
   length of 32 octets for the Nonce extension. The minimum nonce
   length of 1 octet is defined to provide the backward compatibility

Section 3.2:
   If the value of the nonce used by a client in OCSP request is not
   random enough, then an attacker may prefetch responses with the
   predicted nonce and can replay them, thus defeating the purpose of
   using nonce. Therefore the value of Nonce extension in the OCSP
   request MUST contain cryptographically strong randomness and MUST be
   freshly generated at the time of creating the OCSP request. Also
   if the length of the nonce extension is too small e.g. 1 octet then
   an on-path attacker can prefetch responses with all the possible
   values of the nonce and replay a matching nonce.

> Regards,
> Roman
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Mohit Sahni <[email-masked]>
Date: Fri, 14 Aug 2020 17:18:25 -0700

Hi Roman,
I have submitted new version (03) of the draft with the suggested changes,
please review them and let me know if any further changes are needed.

https://datatracker.ietf.org/doc/draft-ietf-lamps-ocsp-nonce/

Thanks
Mohit