Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7143A0538 for ; Sun, 8 Mar 2020 14:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.637 X-Spam-Level: X-Spam-Status: No, score=0.637 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.713, MISSING_HEADERS=1.021, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bWY5dq5wQK7 for ; Sun, 8 Mar 2020 14:30:07 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED7683A0474 for ; Sun, 8 Mar 2020 14:30:06 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id f21so3087271iol.6 for ; Sun, 08 Mar 2020 14:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=5vPTsdTlMQJib1CU1E4ej6eCHMj6PI8jQP/PD0Q+pUI=; b=bc1jx153NqyXJRLZTgsdEPAwOuWfFqjSHk3ROk4Wu2oB4R5JRIQQrQwxhIWSg6uqlJ OyB4DaFCR4gNLLZW2rqf+up9aMmiOvyYjuUBMQxuzkZc2iNUuLyvPqO7F2jMmT2ZCVGx ZnrBLsT5aILe2Y2aIbSnMwzrlJ8V1JUtqCx2T2gABNeKuha/neRz7EhlIhjgeDIRumFg Y4eeKzE6eYldJCIzCthCo93nSe9YM5PSvHtJNlV88LAGHtWoz2anMbCGAzGEVzbE9dD8 Gg5oSVBV7sq36M9+vojphNqAW5kCkFO7sEp7uAB6xks501UNVKLod1HHcEzKAYDsNl/j R88A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=5vPTsdTlMQJib1CU1E4ej6eCHMj6PI8jQP/PD0Q+pUI=; b=udVHWXYu8oXtXG01nrVGFgyW9xsFy/ZueKdlTujjl/1GbSdbEJ/BUG1+I8GFs0ft79 qzf8t9xWO/bulWKNb8WeInhYOtyjCwX7quHTDINwR2CovPjOzJwIwXT4CgFbK515pNUE 9SSu8ZwHZKlrm8itUcXNbPBeT6W2pmqGclQmhQog9HfrUY6i3ZJPW4FEMZj72G2IK1/D DZLkMrLNJ2DqPSlyptZ0yGHx/i9/Vp6XsO5vk1qaALP/WO4dIBwfdikaElvs5MHY2oZA vpSbkGhfYnulXLIYYdcuRl0SeDgsaEB7utq+Gf3CH+Heo0N3D00kICoDp4wys3Yy95wR Yi2A== X-Gm-Message-State: ANhLgQ3tA+kf8mxvbVIdaOipxuJ3tyz6jocXnK1WVbNnJtQhrmCAIyxD dv0szGWmroDiVoFIXJCIq2i7xZmsMUE22691haeiXayo X-Google-Smtp-Source: =?utf-8?q?ADFU+vv4t1kqpl/ZJdAocAaaLay+JpnVgOaf6SwFGiud?= =?utf-8?q?DnTKyKkm5HGyfWDzZ2WC007RSR4utsdqHnvMiu6Ah5YcYUA=3D?= X-Received: by 2002:a05:6638:3ba:: with SMTP id z26mr12037477jap.68.1583703005869; Sun, 08 Mar 2020 14:30:05 -0700 (PDT) MIME-Version: 1.0 References: =?utf-8?q?=3CDM6PR11MB3915D171160F54297CA478E09BE70=40DM6PR11MB3915=2Enampr?= =?utf-8?q?d11=2Eprod=2Eoutlook=2Ecom=3E?= <96FC0A60-3642-4BF3-8237-E204F1F37994@akamai.com> =?utf-8?q?=3C64504da8-289e-70d2-4e87-ed140fa0c100=40primekey=2Ecom=3E_=3CDM?= =?utf-8?q?6PR11MB39154507F7C71DE0134AA8BF9BE70=40DM6PR11MB3915=2Enamprd11?= =?utf-8?q?=2Eprod=2Eoutlook=2Ecom=3E?= In-Reply-To: =?utf-8?q?=3CDM6PR11MB39154507F7C71DE0134AA8BF9BE70=40DM6PR11MB?= =?utf-8?q?3915=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?= From: Mohit Sahni Date: Sun, 8 Mar 2020 14:29:55 -0700 Message-ID: Cc: "spasm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000183eb505a05e9758" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: RFC6960: Issue with the OCSP Nonce extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 21:30:09 -0000 --000000000000183eb505a05e9758 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 openin= g > themselves to replay attacks, but there is no risk to the server. That > contrasts with too-long nonces - DoS and signature forgery attacks - wher= e > 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 stron= g > reason to because "the client is only hurting itself" ? > > --- > Mike Ounsworth | Office: +1 (613) 270-2873 > > -----Original Message----- > From: Spasm 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=E2=80=99s 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 > --000000000000183eb505a05e9758 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,
I have upload=C2=A0a new version of= the draft based on your valuable feedback. Here are the main changes:=C2= =A0
1. Added a section under security considerations about import= ance of using a cryptographically=C2=A0 strong randomness that is freshly g= enerated for the nonce value and about the importance of using a Nonce of l= arger=C2=A0lengths to avoid=C2=A0replays.
2. Modified the section= 2.1 to explicitly=C2=A0mention that server should reject a ocsp request wi= th nonce of more than 32 bytes as malformedRequest error.=C2=A0
3= . Added the following requirements in section 2.1
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 a) The newer clients should use nonce of at-least=C2=A016 byt= es and the minimum length=C2=A0of 1 is specified only for the purpose of ba= ckward compatibility with clients following RFC 6960.=C2=A0
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0b) The Nonce MUST be generated using a crypt= ographically strong=C2=A0pseudorandom number generator.=C2=A0=C2=A0

I hope I have taken care of all the comments, please revi= ew the new version of draft at below mentioned URL and=C2=A0let me know any= further feedback.=C2=A0

Regards,
Mohit=C2=A0
On Mon, Mar 2, 2020 at 2:42 PM Mike Ounsworth <Mike.Ounsworth@entrustdatacard.co= m> 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 con= trasts 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 str= ong 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<= br> Subject: Re: [lamps] [EXTERNAL]Re: RFC6960: Issue with the OCSP Nonce exten= sion

As the Nonce is set by the client the server can not enforce a minimum leng= th. The server typically just copied the nonce from the request into the re= sponse. 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 b= y 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:
>=C2=A0 =C2=A0* I will add text to strongly suggest that a nonce length = should be
>=C2=A0 =C2=A0 =C2=A0between 16-32 octets and make sure implementations = know the risk of
>=C2=A0 =C2=A0 =C2=A0using smaller size nonce.
>
> =C2=A0
>
> That=E2=80=99s 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
--000000000000183eb505a05e9758--