Subject: [lamps] Barry Leiba's Discuss on draft-ietf-lamps-ocsp-nonce-04: (with DISCUSS and COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Thu, 03 Sep 2020 20:56:10 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-lamps-ocsp-nonce-04: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This should be a very easy discussion to have and to resolve:

— Section 2.1 —

   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 with older clients following [RFC6960]
   however, the newer OCSP clients MUST use a length of at least 16
   octets for Nonce extension.

I’m puzzled by this, so please explain: as long as we’re talking about new
clients, developed with this document in place, why shouldn’t it be a MUST to
use 32 octets?  Why would a new client use 16 bits, rather than 32, and what
are the considerations that the coder would need to understand in making that
decision?

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

The rest of my comments are very minor; please consider them, but there’s no
need to respond to them in detail.  Thanks.

General nit: I find the use of “the” in citations to be jarring, as it’s
uncustomary... we normally say “in RFC 6960”, not “in the RFC 6960”.  I’m sure
the RFC Editor will sort that out for consistency within the series, though it
might not be a bad thing to help them out in advance.  I note odd use of “the”
throughout the document as well, with extraneous “the” in various places, and
missing “the” in others.

Also, please check for consistency in capitalization of “Nonce extension” vs
“nonc extension” throughout.

— Section 1 —

   Due to not having an upper or lower limit of the length of the Nonce
   extension, the OCSP responders that follow [RFC6960] may be
   vulnerable to various attacks like Denial of Service attacks
   [RFC4732], chosen prefix attacks to get a desired signature from the
   OCSP responder and possible evasions that can use the Nonce extension
   data for evasion.

Nit: The length of this sentence makes me want the Oxford comma in the list:
please add a comma after “OCSP responder” to aid the readability.  (One could
also shorten the sentence by, “Lacking limits on the length of the Nonce
extension, ...”)

— Section 2 —
It’s a small thing, but I found myself wondering why you include a list of OCSP
extensions, and then say that you only care about Nonce here.  What’s the
benefit to the reader of mentioning the others at all?

— Section 3.1 —

   The Nonce extension is used to avoid replay attacks.

Another small thing: You say this in the Abstract and in Sections 2.1, 3, and
3.1.  By the time I got to 3.1 I wondered why the repetition was needed.

— Section 3.2 —

   If the value of the nonce used by a client in OCSP request is not
   random enough,

I find “is not random enough” to be odd, and kind of vague.  What you mean here
is really “is not random and has an element of predictability,” yes?

---

From: Mohit Sahni <[email-masked]>
Date: Thu, 3 Sep 2020 22:29:29 -0700

Hi Barry,
The reason for using a SHOULD instead of MUST was to make sure that new
OCSP responders following this draft can still interoperate with existing
OCSP clients that may never get upgraded and still send a smaller sized
Nonce extension (for example OpenSSL library currently uses Nonce extension
of length 16 octets). In my opinion, having a "MUST" instead of "SHOULD"
contravene the specification of 16-32 octets range for the Nonce extension
length which is required for backward compatibility. Backward compatibility
was one of the main factors in my mind while writing the draft since OCSP
is a widely used protocol.

I hope I am able to explain the reason behind using a SHOULD instead of
MUST in section 2.1.

Regarding the comment for section 3.1 ("not random enough"), you are
correct, my intention is to point out that if the source for randomness
(seed) is not good, then the next sequence in the random number stream can
be guessed by someone if they are provided with enough data from that
stream of random numbers.

Thanks for the other comments, I will go over them and make the required
changes to make the draft more consistent and readable.

Regards,
Mohit Sahni

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

---

From: Barry Leiba <[email-masked]>
Date: Fri, 4 Sep 2020 08:43:04 -0400

Hi, Mohit, and thanks for the quick response.

> The reason for using a SHOULD instead of MUST was to make sure that
> new OCSP responders following this draft can still interoperate with
> existing OCSP clients that may never get upgraded and still send a
> smaller sized Nonce extension (for example OpenSSL library currently
> uses Nonce extension of length 16 octets). In my opinion, having a
> "MUST" instead of "SHOULD" contravene the specification of 16-32
> octets range for the Nonce extension length which is required for
> backward compatibility. Backward compatibility was one of the main
> factors in my mind while writing the draft since OCSP is a widely used
> protocol.

OK, yes, that's what I expected, which is why my comment stresses the
"new clients" aspect.  It seems to me that the text should say that
*new* clients MUST use 32 octets, and that smaller values are only for
backward compatibility.  I don't see the reason to say that *new*
clients SHOULD use 32 and MUST use at least 16.

Let me suggest alternative text, and please let me know whether this
is suitable, or tell me why it is not:

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

NEW
   The minimum nonce length of 1 octet is defined to provide
   backward compatibility with older clients that follow [RFC6960].
   Newer OCSP clients that support this document MUST use a
   length of 32 octets for the Nonce extension.  OCSP responders
   MUST accept lengths of at least 16 octets, and  MAY choose to
   ignore the Nonce extension for requests where the length of the
   Nonce extension is less than 16 octets.

Barry

---

From: Mohit Sahni <[email-masked]>
Date: Fri, 4 Sep 2020 07:07:08 -0700

Thanks, Barry, your suggestion looks good to me. If there is no objection
from anyone then I will make that change.

- Mohit

On Fri, Sep 4, 2020 at 5:43 AM Barry Leiba <[email-masked]> wrote:

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spasm&d=DwIFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=J7DgfMyeL26OZuy8d3qTy_h24Ff1NatxSKMgDUj2Kxg&m=BrlyxC-lvmCXnlQZCmz1X049NdHN9HpRCEGmWy8mNFs&s=7kHDL_wyUHlRC_V30QSOAYiXy8pP2cceg1YKQswyhTU&e=
>

---

From: Barry Leiba <[email-masked]>
Date: Fri, 4 Sep 2020 13:26:57 -0400

Thanks, Mohit.

Barry

On Fri, Sep 4, 2020 at 10:07 AM Mohit Sahni <[email-masked]> wrote:
>
> Thanks, Barry, your suggestion looks good to me. If there is no objection from anyone then I will make that change.
>
> - Mohit
>

---

From: Mohit Sahni <[email-masked]>
Date: Sun, 6 Sep 2020 15:11:08 -0700

Hi Barry
Here is the delta of changes I made to the draft as per your valuable
suggestions. Please let me know if they look ok. I am holding off
publishing a new draft in case there are any other changes required.

https://github.com/mohitsahni/ocsp-nonce/commit/79a6f0956fa62a05e39ec2efe8b19a0145ab1bdb

-Mohit

On Fri, Sep 4, 2020 at 10:27 AM Barry Leiba <[email-masked]> wrote:

> > Thanks, Barry, your suggestion looks good to me. If there is no
> objection from anyone then I will make that change.
> >
> > - Mohit
> >

---

From: Mohit Sahni <[email-masked]>
Date: Thu, 10 Sep 2020 11:16:27 -0700

Hi Barry,
I have published a new version of the draft at
https://datatracker.ietf.org/doc/draft-ietf-lamps-ocsp-nonce/?include_text=1
can you please have a look at it and see if it resolves your DISCUSS ballot
position.

Thanks
Mohit