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

From: Roman Danyliw <[email-masked]>
Date: Mon, 27 Jul 2020 01:59:50 +0000

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/

** 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.

** 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?

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

** 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?

** 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").  

** 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?

Regards,
Roman

---

From: Mohit Sahni <[email-masked]>
Date: Mon, 27 Jul 2020 10:25:24 -0700

Hi Roman,
Thanks for your feedback, I will make these changes and upload the new
version of the draft.

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.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.
>
> ** 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?
>
> ** 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?
>
> -- 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").
>
> ** 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?
>
> Regards,
> Roman
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>