Re: [lamps] Paul Wouters' Yes on draft-ietf-lamps-cms-kemri-08: (with COMMENT)

[Russ Housley <[e-mail]>]

Paul:

> On Mar 5, 2024, at 4:14 PM, Paul Wouters via Datatracker <[e-mail]> wrote:
> 
> Paul Wouters has entered the following ballot position for
> draft-ietf-lamps-cms-kemri-08: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-kemri/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks to Brian Weis for the SecDir review. I think there are some good
> suggestions in there. Please take those into consideration:
> 
> https://datatracker.ietf.org/doc/review-ietf-lamps-cms-kemri-06-secdir-lc-weis-2023-10-24/
> 
> I had one question myself:
> 
>        Implementations that do not support the ukm field SHOULD
>        gracefully discontinue processing when the ukm field is present.
> 
> Can this field be present and empty/zero-length ? If so, does this
> affect the SHOULD above?

RFC 5652 says:

10.2.6.  UserKeyingMaterial

   The UserKeyingMaterial type gives a syntax for user keying material
   (UKM).  Some key agreement algorithms require UKMs to ensure that a
   different key is generated each time the same two parties generate a
   pairwise key.  The sender provides a UKM for use with a specific key
   agreement algorithm.

      UserKeyingMaterial ::= OCTET STRING

Then, this document says:

      ukm is optional user keying material.  When the ukm value is
      provided, it is used as part of the info structure described in
      Section 5 to provide a context input to the key-derivation
      function.  For example, the ukm value could include a nonce,
      application-specific context information, or an identifier for the
      originator.  A KEM algorithm may place requirements on the ukm
      value.  Implementations that do not support the ukm field SHOULD
      gracefully discontinue processing when the ukm field is present.
      Note that this requirement expands the original purpose of the ukm
      described in Section 10.2.6 of [RFC5652]; it is not limited to
      being used with key agreement algorithms.

So, this syntax does allow a zero length OCTET STRING, but that would not be useful.

I'll add a sentence to this document that requires the UKM to be at least one octet if it is present.

Russ