Subject: [lamps] RFC6960: Issue with the OCSP Nonce extension

From: Mohit Sahni <[email-masked]>
Date: Sat, 7 Dec 2019 12:30:02 -0800

Hi All,
The section 4.1.1 of the RFC6960 describes the format and ID for the Nonce
extension in the OCSP request and response. According to the RFC the nonce
will have the identifier id-pkix-ocsp-nonce and the type of the Nonce is an
OCTATE STRING.  The problem I see is that the RFC does not mention whether
the nonce should be of fixed length or should have a maximum length. Due to
this reason the current implementations that follow this standard can
accept very large OCSP requests and are vulnerable to denial of service
attacks and various evasion tricks using the nonce field as a tunnel. Since
most of the OCSP requests don't use TLS as transport someone in the path
can also modify the HTTP request to inject large nonce thus making the
situation worse.

I would like to propose that the standard MUST define a maximum length for
Nonce or the Nonce MUST be of a defined fixed length. I lean towards
proposing the standard to have a maximum value of 256 bytes and minimum
value of 1 byte to make it backward compatible.

Do you guys think it makes sense and if I should propose a draft for making
Nonce length with a maximum of 256 and minimum of 1.

Here is the text from section 4.1.1 of RFC6960:

   The nonce cryptographically binds a request and a response to prevent
   replay attacks.  The nonce is included as one of the
   requestExtensions in requests, while in responses it would be
   included as one of the responseExtensions.  In both the request and
   the response, the nonce will be identified by the object identifier
   id-pkix-ocsp-nonce, while the extnValue is the value of the nonce.

     id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp }
     id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

     Nonce ::= OCTET STRING

-Mohit

---

From: Russ Housley <[email-masked]>
Date: Sat, 7 Dec 2019 15:47:40 -0500

It seems like the easiest fix is to update the ASN.1 to be:

    Nonce ::= OCTET STRING (SIZE(1..256))

Your paragraph seems like the introduction to the update document.

Russ

> On Dec 7, 2019, at 3:30 PM, Mohit Sahni <[email-masked]> wrote:
> 
> Hi All,
> The section 4.1.1 of the RFC6960 describes the format and ID for the Nonce extension in the OCSP request and response. According to the RFC the nonce will have the identifier id-pkix-ocsp-nonce and the type of the Nonce is an OCTATE STRING.  The problem I see is that the RFC does not mention whether the nonce should be of fixed length or should have a maximum length. Due to this reason the current implementations that follow this standard can accept very large OCSP requests and are vulnerable to denial of service attacks and various evasion tricks using the nonce field as a tunnel. Since most of the OCSP requests don't use TLS as transport someone in the path can also modify the HTTP request to inject large nonce thus making the situation worse. 
> 
> I would like to propose that the standard MUST define a maximum length for Nonce or the Nonce MUST be of a defined fixed length. I lean towards proposing the standard to have a maximum value of 256 bytes and minimum value of 1 byte to make it backward compatible. 
> 
> Do you guys think it makes sense and if I should propose a draft for making Nonce length with a maximum of 256 and minimum of 1. 
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Mohit Sahni <[email-masked]>
Date: Sat, 7 Dec 2019 13:54:08 -0800

Thanks Russ, I will work on writing a draft.

On Sat, Dec 7, 2019 at 12:47 PM Russ Housley <[email-masked]> wrote:

> > The section 4.1.1 of the RFC6960 describes the format and ID for the
> Nonce extension in the OCSP request and response. According to the RFC the
> nonce will have the identifier id-pkix-ocsp-nonce and the type of the Nonce
> is an OCTATE STRING.  The problem I see is that the RFC does not mention
> whether the nonce should be of fixed length or should have a maximum
> length. Due to this reason the current implementations that follow this
> standard can accept very large OCSP requests and are vulnerable to denial
> of service attacks and various evasion tricks using the nonce field as a
> tunnel. Since most of the OCSP requests don't use TLS as transport someone
> in the path can also modify the HTTP request to inject large nonce thus
> making the situation worse.
> >
> > I would like to propose that the standard MUST define a maximum length
> for Nonce or the Nonce MUST be of a defined fixed length. I lean towards
> > Do you guys think it makes sense and if I should propose a draft for
> making Nonce length with a maximum of 256 and minimum of 1.
> >

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 9 Dec 2019 08:56:24 +0100

Hi,

There was a discussion about this a few years back in Mozilla dev security.
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/x3TOIJL7MGw
Back then the motivation was the risk of a chosen-prefix attack.

We ended up limiting Nonce to 32 bytes:
https://jira.primekey.se/browse/ECA-4906

32 bytes has caused no issues globally during these past three years. Of
course, moving the limit to 256 bytes is a no-brainer.

Is there some common best practice limit (32 in our case) that could
function as a basis for the new max value?

Cheers,
Tomas

On 2019-12-07 22:54, Mohit Sahni wrote:
> On Sat, Dec 7, 2019 at 12:47 PM Russ Housley <[email-masked]
> <mailto:housley@vigilsec..com>> wrote:
> 
>     > On Dec 7, 2019, at 3:30 PM, Mohit Sahni <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > Hi All,
>     > The section 4.1.1 of the RFC6960 describes the format and ID for
>     the Nonce extension in the OCSP request and response. According to
>     the RFC the nonce will have the identifier id-pkix-ocsp-nonce and
>     the type of the Nonce is an OCTATE STRING.  The problem I see is
>     that the RFC does not mention whether the nonce should be of fixed
>     length or should have a maximum length. Due to this reason the
>     current implementations that follow this standard can accept very
>     large OCSP requests and are vulnerable to denial of service attacks
>     and various evasion tricks using the nonce field as a tunnel. Since
>     most of the OCSP requests don't use TLS as transport someone in the
>     path can also modify the HTTP request to inject large nonce thus
>     > I would like to propose that the standard MUST define a maximum
>     length for Nonce or the Nonce MUST be of a defined fixed length. I
>     lean towards proposing the standard to have a maximum value of 256
>     bytes and minimum value of 1 byte to make it backward compatible.
>     >
>     > Do you guys think it makes sense and if I should propose a draft
>     for making Nonce length with a maximum of 256 and minimum of 1.
>     >
>     > [email-masked] <mailto:[email-masked]>

---

From: Russ Housley <[email-masked]>
Date: Mon, 9 Dec 2019 08:15:36 -0500

I do not know of any situation where 32 bytes is not enough for a nonce.

Russ

> On Dec 9, 2019, at 2:56 AM, Tomas Gustavsson <[email-masked]> wrote:
> 
> Hi,
>