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

Hi All,
I have upload a new version of the draft based on your valuable feedback.
Here are the main changes:
1. Added a section under security considerations about importance of using
a cryptographically  strong randomness that is freshly generated for the
nonce value and about the importance of using a Nonce of larger lengths to
avoid replays.
2. Modified the section 2.1 to explicitly mention that server should reject
a ocsp request with nonce of more than 32 bytes as malformedRequest error.
3. Added the following requirements in section 2.1
        a) The newer clients should use nonce of at-least 16 bytes and the
minimum length of 1 is specified only for the purpose of backward
compatibility with clients following RFC 6960.
         b) The Nonce MUST be generated using a cryptographically
strong pseudorandom number generator.

I hope I have taken care of all the comments, please review the new version
of draft at below mentioned URL and let me know any further feedback.
https://datatracker.ietf.org/doc/draft-msahni-lamps-ocsp-nonce/

Regards,
Mohit

On Mon, Mar 2, 2020 at 2:42 PM Mike Ounsworth <
Mike.Ounsworth@entrustdatacard.com> wrote:

> As I understand it, a client using a short or low-entropy nonce is opening
> themselves to replay attacks, but there is no risk to the server. That
> contrasts with too-long nonces - DoS and signature forgery attacks - where
> the risk is to the server.
>
> An OCSP responder *could* enforce a minimum nonce length in the same way -
> by rejecting requests that don't conform - but maybe there is not a strong
> reason to because "the client is only hurting itself" ?
>
> ---
> Mike Ounsworth | Office: +1 (613) 270-2873
>
> -----Original Message-----
> From: Spasm <spasm-bounces@ietf.org> On Behalf Of Tomas Gustavsson
> Sent: March 2, 2020 3:59 PM
> To: spasm@ietf.org
> Subject: Re: [lamps] [EXTERNAL]Re: RFC6960: Issue with the OCSP Nonce
> extension
>
> As the Nonce is set by the client the server can not enforce a minimum
> length. The server typically just copied the nonce from the request into
> the response. Now it's also checking that the client does not send more
> than 32 bytes as nonce and will give a Unauthorized response if the nonce
> sent by the client is >32 bytes.
>
> So, there is a client-server separation.
> - minimal size is a recommendation for OCSP clients
> - maximum size is a limit enforced by the OCSP responder
>
> Cheers,
> Tomas
>
> On 2020-03-02 13:50, Salz, Rich wrote:
> >   * I will add text to strongly suggest that a nonce length should be
> >     between 16-32 octets and make sure implementations know the risk of
> >     using smaller size nonce.
> >
> >
> >
> > That’s fine with me, thanks.
> >
> >
> > _______________________________________________
> > Spasm mailing list
> > Spasm@ietf.org
> > https://www.ietf.org/mailman/listinfo/spasm
> >
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>