Re: [Last-Call] [EXTERNAL] Secdir last call review of draft-ietf-lamps-ocsp-nonce-update-04

[Joseph Salowey <[e-mail]>]

Hi Himanshu,

Thank you for the excellent summary below and for addressing my questions
and concerns.  The updated draft resolves my outstanding issues and I think
it is ready to go.

Cheers,

Joe

On Mon, Apr 8, 2024 at 10:24 PM Himanshu Sharma <[e-mail]>
wrote:

> Hi Joseph
>     In case the updated I-D was missed, I am trying to put the email on
> top.
> Here I am summarizing our off-line discussion so that everyone in the
> group will be on the same page.
>
> [Joe] So 32 bytes will hopefully help interoperability.
> [HS] Yes, I mentioned and explained the decision and discussion related to
> RFC8954 and keeping the same Nonce length recommendation (32 bytes) for
> interoperability purposes. I believe that the concern related to length of
> 32 bytes has been addressed.
>

> [Joe] I think it is better to have a MUST.  It should result in better
> interoperability.  (referring the section 2.1 para 2)
> [HS] I have updated I-D to version 05 to include the "MUST" inplace of
> "SHOULD"  As per your feedback and discussion.
> Now I-D 05 mentions
> "An OCSP client that implements this document MUST use a minimum
>    length of 32 octets for Nonce octets in the Nonce extension. "
>
>
> [Joe] With current deployed behavior servers can choose not to support the
> nonce extension and ignore it.  For servers that do support the nonce
> extension would it be acceptable to say that they have to respond to the
> nonce extension if it is between 16 and 128 bytes? Or are there servers
> that will just ignore nonces greater that 32 bytes (instead of sending an
> error).
> [HS] With this Draft we are making sure that the server that supports
> Nonce, MUST support the nonce between 16-32  and may choose to ignore the
> nonce between 1-to-16 and 33-to-128 bytes.
>
>
> [Joe] What do clients typically do if they do not get a nonce in response,
> do they reject the response?"
> [HS] Most of the clients just log a warning message and accept
> the response. As few public responders do not support nonce for performance
> reasons.
>
>
> I believe the I-D 05 version  (
> https://datatracker.ietf.org/doc/draft-ietf-lamps-ocsp-nonce-update/05/)
> addresses your concerns. Please let me know if there is any outstanding
> concern that I can answer.
>
> -Himanshu
>
>
> On Thu, Apr 4, 2024 at 11:58 AM Himanshu Sharma <[e-mail]>
> wrote:
>
>> Hi Joseph,
>>   As discussed offline, explained and agreed upon the reason for choosing
>> the 32 bytes primarily for backward compatibility, and explained about the
>> behavior of ocsp client in case of response that doesn't contain nonce from
>> responder.
>> I have updated the ID (
>> https://datatracker.ietf.org/doc/draft-ietf-lamps-ocsp-nonce-update/05/)
>> according to your and other reviewr's suggestions.
>> Russ helped in verification of ASN.1 modules and it compiles fine.
>>
>> I believe it satisfies all the outstanding questions.
>>  Please let me know if there are still any outstanding questions that I
>> can answer in order to get the approval.
>>
>> Thanks
>> Himanshu
>>
>>
>>
>>
>> On Sun, Mar 31, 2024 at 12:21 PM Joseph Salowey via Datatracker <
>> [e-mail]> wrote:
>>
>>> Reviewer: Joseph Salowey
>>> Review result: Has Issues
>>>
>>> I have reviewed this document as part of the security directorate's
>>> ongoing effort to review all IETF documents being processed by the
>>> IESG. These comments were written primarily for the benefit of the
>>> security area directors. Document editors and WG chairs should treat
>>> these comments just like any other last call comments.
>>>
>>> The summary of the review is has issues.  I'm probably just missing some
>>> history/context, here are the items that stood out.
>>>
>>> 1. The document states "An OCSP client that implements this document
>>> SHOULD use
>>> a minimum length of 32 octets for Nonce octets in the Nonce extension."
>>> How
>>> was the minimum of 32 bytes chosen? This seems like it might be longer
>>> than
>>> necessary. Is there a security reason for this or a different reason?
>>> Later in
>>> the document it states receiver MUST accept at least 16 octets.
>>>
>>> 2. In addition, the SHOULD should say when it is acceptable not to
>>> follow it.
>>> When is it OK for an implementation to send less than 32 bytes?  For
>>> example,
>>> you could rephrase this as "clients MUST use a minimum length of 32
>>> octets
>>> unless they are configured to interoperate with a OCSP responder that
>>> requires
>>> a shorter nonce length or ... ".  Also if a client uses more than 32
>>> bytes
>>> their request may be ignored.
>>>
>>> 3. An 8954 server will respond to greater than 32 octet nonce with a
>>> malformedRequest. The client can report this and indicate that perhaps
>>> it needs
>>> to be configured to talk to an 8954 server. The text goes further to say
>>> that
>>> the server MAY ignore nonces greater than 32 and less than 16 octets.
>>> Does this
>>> mean that the response does not contain the nonce? What should the
>>> client do in
>>> this case? Why even allow responders to ignore a nonce that is greater
>>> than 32
>>> octets?
>>>
>>> 4. I took a look at the ASN.1, it looks OK to me, but I'm a bit rusty. I
>>> assume
>>> that it was reviewed by the working group, it not then someone with more
>>> recent
>>> ASN.1 experience should look at it.
>>>
>>>
>>>