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

[Himanshu Sharma <[e-mail]>]

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.
>>
>>
>>