Subject: [lamps] Benjamin Kaduk's Yes on draft-ietf-lamps-ocsp-nonce-04: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 09 Sep 2020 10:29:48 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lamps-ocsp-nonce-04: Yes

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:
----------------------------------------------------------------------

Just some nits of varying severity from me...

Abstract

   This document specifies the updated format of the Nonce extension in
   Online Certificate Status Protocol (OCSP) request and response

nit(?): is it the format itself that is specified or constraints upon
the format?

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: "evasions that can use [...] for evasion" is slightly awkward
wording.  Could we say something different about what is being evaded?

                      This document specifies a lower limit of 1 and an
   upper limit of 32 to the length of the Nonce extension.  This

(pedantic nit): the length of the extension, or the length of the OCTET
STRING bearining the nonce value, contained in the extension?

Section 2

Thanks for agreeing to remove the unrelated list of OCSP extnsions.

Section 2.1

I'm happy to see the discussion with Barry about mandating the behavior
of new clients more tightly without breaking old clients.

   A server MUST reject any OCSP request having a Nonce extension with
   length of 0 octets or more than 32 octets with the malformedRequest
   OCSPResponseStatus as described in section 4.2.1 of [RFC6960].

(same nit about exactly which length is being constrained.)

Section 3.1

(side note) the bit about the Nonce being optional in the response even
if it was present in the request is actually in 6960 itself if you read
carefully; 5019 has a bit more exposition on it but may not, strictly
speaking, be a necessary reference.

Section 5.x

[I expect that the RFC Editor will adjust the formatting/wording a bit,
especially since "old syntax" and "new syntax" in the context of 1998
vs. 2008 ASN.1 syntax is probably going to make people think ASN.1, as
opposed to "OLD text" and "NEW text" or just "OLD"/"NEW".]

---

From: Mohit Sahni <[email-masked]>
Date: Wed, 9 Sep 2020 12:24:40 -0700

Hi Ben,
Thanks for the reviewing and providing the comments; Please see my response
inline with the comments.

To avoid confusion we are specifying the new format instead of just
constraints. (based on the comment from Roman)

> I have reworded this statement in the upcoming draft, statement line will
look like this in the next draft:

   "may be vulnerable to various attacks
   like Denial of Service attacks [RFC4732], chosen prefix attacks to
   get a desired signature, and possible evasions using the Nonce
   extension data"
In the context of network security, the word evasion is commonly used for
techniques that a malicious application uses to avoid detection by a
security device, for example, a malicious application may be uploading the
data from the victim's computer to a remote server using the payload in the
Nonce extension of OCSP requests made to the server.

> STRING bearining the nonce value, contained in the extension?
Thanks for pointing out, I will make the change to call it as Length of the
Nonce Extension value.

> (same nit about exactly which length is being constrained.)

Will Fix that.

> speaking, be a necessary reference.
I am sorry, I am not able to find specific text in RFC 6960 which tells
that Nonce can be omitted in the response of an OCSP query containing the
Nonce extension and how a client should handle the case where it does not
find the nonce extension in the response. Can you please point out the
specific text in RFC 6960 and I will update the reference.

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 9 Sep 2020 12:49:59 -0700

Hi Mohit,

On Wed, Sep 09, 2020 at 12:24:40PM -0700, Mohit Sahni wrote:
>    Hi Ben,
>    Thanks for the reviewing and providing the comments; Please see my
>    response inline with the comments.
>     
> 

Okay, thanks.

>    data from the victim's computer to a remote server using the payload in
>    the Nonce extension of OCSP requests made to the server. 
>     
> 
>    Thanks for pointing out, I will make the change to call it as Length of
>    the Nonce Extension value. 
>     
> 
>      Section 2
> 

It's pretty buried, yes, but I think it falls out from the generic
extension handling description.  Even in the Section 2.1 overview of a
Request, they are "optional extensions, which MAY be processed by the OCSP
responder" (implying that they may be ignored as well); similarly in
Section 4.1.2 and 4.4.  So even though the definition of the Nonce
extension in Sectino 4.4.1 says that it is "included as one of the
responseExtensions", that's only if the server elects to do so (and
supports it in the first place).

Thanks,

Ben