Subject: [lamps] Robert Wilton's No Objection on draft-ietf-lamps-ocsp-nonce-04: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Mon, 07 Sep 2020 04:34:50 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-lamps-ocsp-nonce-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-ocsp-nonce/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

This document is simple and easy to read and understand, to thank your for that.

As someone with little security knowledge, I was left wondering how the
determination of what length nonce is required is made?  E.g., is there some
calculation that is performed that concludes that 16 bytes is okay, but 32 is
better and any longer is pointless?  Or is that described in another document
that could be referenced (perhaps this is covered by the last parts of rfc4086)?

Hence, my comment on this document is whether it would be helpful to have any
background text that explains why the particular length(s) of nonce has been
chosen.

Regards,
Rob

---

From: Mohit Sahni <[email-masked]>
Date: Mon, 7 Sep 2020 14:06:21 -0700

Hi Rob,
Thanks for reviewing the draft. The Nonce in an OCSP request is not used to
derive any further keys or hashes (although it becomes part of the signed
response), rather just copied back in the response to indicate that server
has generated a fresh response. The recommended value of random 32
octets was chosen to make sure Nonce is not small enough to be predicted by
anyone (to protect the clients) and not large enough to be misused to
exploit an OCSP responder.

Based on Barry's feedback, I will modify the draft to specify that the
Clients that follow this document MUST only use a nonce of length 32
octets, I hope that will make it cleaner to implement the specification.

Regards,
Mohit

On Mon, Sep 7, 2020 at 4:34 AM Robert Wilton via Datatracker <
[email-masked]> wrote

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 8 Sep 2020 09:45:49 +0000

Hi Mohit,

I’m not sure that this really matters, but I was hoping for a calculation that shows that a smaller nonce has too much risk or being guessed, or some guidance or documentation that indicates that nonces should generally be X bits long.  But perhaps there is just common wisdom over what size is advisable.

E.g., this stackoverflow answer (which is 10 years old and may not be right) suggests that an 8 octet (64 bit) nonce is generally sufficient, but now we are going with 32 octets here.  I guess that I am wondering whether the extra octets give practical additional security over a shorter nonce … https://security.stackexchange.com/questions/1952/how-long-should-a-random-nonce-be

A separate issue that we may want to consider relates to use of the word/term “nonce”.  In British English this term is slang for a paedophile, https://dictionary.cambridge.org/dictionary/english/nonce

I’m not saying that we should necessarily change this, but we might want to consider whether there is an alternative equivalent term that could be used instead.

Regards,
Rob

From: Mohit Sahni <[email-masked]>
Sent: 07 September 2020 22:06
To: Rob Wilton (rwilton) <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; LAMPS WG <[email-masked]>; Russ Housley <[email-masked]>
Subject: Re: Robert Wilton's No Objection on draft-ietf-lamps-ocsp-nonce-04: (with COMMENT)

Hi Rob,
Thanks for reviewing the draft. The Nonce in an OCSP request is not used to derive any further keys or hashes (although it becomes part of the signed response), rather just copied back in the response to indicate that server has generated a fresh response. The recommended value of random 32 octets was chosen to make sure Nonce is not small enough to be predicted by anyone (to protect the clients) and not large enough to be misused to exploit an OCSP responder.

Based on Barry's feedback, I will modify the draft to specify that the Clients that follow this document MUST only use a nonce of length 32 octets, I hope that will make it cleaner to implement the specification.

Regards,
Mohit

On Mon, Sep 7, 2020 at 4:34 AM Robert Wilton via Datatracker <[email-masked]<mailto:[email-masked]>> wrote

Hi,

Regards,
Rob