Subject: [lamps] WG Last Call for draft-ietf-lamps-ocsp-nonce-01

From: Russ Housley <[email-masked]>
Date: Mon, 27 Apr 2020 10:56:22 -0400

This is the LAMPS WG Last Call for "OCSP Nonce Extension” <draft-ietf-lamps-ocsp-nonce-01>.  Please review the document and send your comments to the list by 12 May 2020.

The datatracker page for the document is https://datatracker.ietf.org/doc/draft-ietf-lamps-ocsp-nonce/

Thanks,
Russ & Tim

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 27 Apr 2020 17:40:00 +0000

Nit in the abstract:
	OCSP responder [insert oxford comma here] and possible evasions

Section 2.1
	newer OCSP clients MUST use length of at least 16 octets for Nonce
Should MUST be a SHOULD?  Don't care either way since it says "newer clients"

Looks good to me, ship it.

---

From: Corey Bonnell <[email-masked]>
Date: Thu, 30 Apr 2020 01:21:54 +0000

Section 2.1 mandates that "newer clients" MUST send a nonce of at least 16 octets output from a CSPRNG. However, section 3.2 specifies that clients SHOULD send 32-octet nonces.

Given that newer clients would not be bound by legacy limitations and could presumably support 32-octet nonces, is there a compelling reason to specify two different lengths in the two sections? It seems to me it would be preferable to have alignment with the guidance for newer client implementations and recommended best practice in the Security Considerations.

Thanks,
Corey

________________________________
From: Spasm <[email-masked]> on behalf of Salz, Rich <rsalz=[email-masked]>
Sent: Monday, April 27, 2020 1:40 PM
To: Russ Housley <[email-masked]>; LAMPS WG <[email-masked]>
Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-ocsp-nonce-01

Nit in the abstract:

Section 2.1

_______________________________________________
Spasm mailing list
[email-masked]
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=02%7C01%7C%7C89e67c46d5fd4966ff0a08d7ead21ddc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637236060478859670&amp;sdata=Ol3rSY9uu7Fi3Rjv17KXVV4M%2FWNXJjBgXpWZSxB0oOg%3D&amp;reserved=0

---

From: Mohit Sahni <[email-masked]>
Date: Wed, 29 Apr 2020 21:02:06 -0700

Hi Corey
The intention here is to provide a recommended value of 32 bytes and set a
lower bound of 16 bytes along with making sure the specification is
backward compatible for older clients that talk to new responders. I choose
a lower bound of 16 bytes as most of the implementations including OpenSSL
uses 16 bytes of nonce by default. Giving a range instead of fixed length
provides more flexibility and makes it even more secure by adding one more
attribute for an attacker to figure out to guess the nonce. Think of it as
trying to guess a fixed size password compared to a variable size password.

Thanks
Mohit

On Wed, Apr 29, 2020 at 6:22 PM Corey Bonnell <[email-masked]> wrote:

> Section 2.1 mandates that "newer clients" MUST send a nonce of at least 16
> octets output from a CSPRNG. However, section 3.2 specifies that clients
> SHOULD send 32-octet nonces.
>
> Given that newer clients would not be bound by legacy limitations and
> could presumably support 32-octet nonces, is there a compelling reason to
> specify two different lengths in the two sections? It seems to me it would
> be preferable to have alignment with the guidance for newer client
> implementations and recommended best practice in the Security
> Considerations.
>
> Thanks,
> Corey
>
> ------------------------------
> *From:* Spasm <[email-masked]> on behalf of Salz, Rich <rsalz=
> [email-masked]>
> *Sent:* Monday, April 27, 2020 1:40 PM
> *To:* Russ Housley <[email-masked]>; LAMPS WG <[email-masked]>
> *Subject:* Re: [lamps] WG Last Call for draft-ietf-lamps-ocsp-nonce-01
>
> Nit in the abstract:
> https://www.ietf.org/mailman/listinfo/spasm
>