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

[Russ Housley <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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:
>> Thanks Russ, I will work on writing a draft. 
>> 
>> On Sat, Dec 7, 2019 at 12:47 PM Russ Housley <[e-mail]
>> <mailto:housley@vigilsec..com>> wrote:
>> 
>>    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 <[e-mail]
>>    <mailto:[e-mail]>> 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.
>>> 
>>> 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
>>> _______________________________________________
>>> Spasm mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/spasm
>> 
>> 
>> _______________________________________________
>> Spasm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spasm
>> 
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm