Re: [secdir] secdir review of draft-ietf-lamps-cms-sha3-hash

[Wes Hardaker <[e-mail]>]

Russ Housley <[e-mail]> writes:

Thanks for the response Russ.  Trimming back-and-forth to just a few
things.

> > - section 3.1 and beyond: there is a discrepancy between how OIDs are
> >  used in some places and the fully qualified OBJECT IDENTIFIERs are
> >  used in other places.  I note the appendix uses OID everywhere, but
> >  the copied versions into the sections above.
> 
> The OID convention was used only is Section 3.1 because the names that
> were already assigned in RFC 8017 are so long.  If you find this
> confusing, the impact will be two lines for each of them.

It makes more sense to do the inverse then and change the rest of the
invocations to OID as well.  This actually matches the real module's use
anyway.

But there is no "wrong" way here.  Your choice in the end.

> > - section 5.2: suggest changing "If any other value is used for S" to
> >  "If any value is used for S", since you just said it must be absent if
> >  there was no label.  And unless "absent" is a value, then the word
> >  "other" doesn't apply.
> 
> Based on an earlier comment, this was changed to:
> 
>    When the id-kmac128 or id-kmac256 is used as part of an algorithm
>    identifier, the parameters field MUST be absent when there is no
>    customization label S.  If any value is provided for S, then the
>    parameters field MUST be present and contain the value of S, encoded
>    as Customization.

Thanks...  I actually reviewed an earlier version and then looked at the
diff to fix my review, but missed one.

>    ...  Instead of brute force searching the whole
>    key space, an attacker may find it much easier to reproduce the PRNG
>    environment that produced the keys, and then search the resulting
>    small set of possibilities.  ...

That's definitely better, thanks.

-- 
Wes Hardaker
USC/ISI