Last Call Review of draft-ietf-ippm-encrypted-pdmv2-05
review-ietf-ippm-encrypted-pdmv2-05-secdir-lc-lonvick-2024-01-15-00

Hi,

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

The document explains the use of a lightweight handshake and encryption
protocol for the PDM destination option. I found it to be readable and to
explain how to use the protocol.

I found a few nits that the authors may wish to review.

Second paragraph in Section 1
Current: a timing attack MAY be launched against
Proposed: a timing attack may be launched against
(This isn't a directive in the protocol so doesn't fall under BCP 14.)

Second paragraph of Section 5.4
Current:
   Our choice is to use the HPKE framework that incorporates key
   encapsulation mechanism (KEM), key derivation function (KDF) and
   authenticated encryption with associated data (AEAD).  These multiple
   schemes are more robust and significantly efficient than the
   traditional schemes and thus lead to our choice of this framework.
   We recommend default encryption algorithm for HPKE AEAD as AES-
   128-GCM, however this is an implementation choice and can be
   negotiated between the communicating parties.
Proposed:
   It is RECOMMENDED to use the HPKE framework that incorporates key
   encapsulation mechanism (KEM), key derivation function (KDF) and
   authenticated encryption with associated data (AEAD).  These multiple
   schemes are more robust and significantly more efficient than other
   schemes. While the schemes may be negotiated between communicating
   parties, it is RECOMMENDED to use default encryption algorithm for
   HPKE AEAD as AES-128-GCM.

Somewhere in Section 6.3
Current:
      This field is also used in the Encrypted PDMv2 as the encryption
      nonce.
Proposed:
      This field is also used in the Encrypted PDMv2 as the encryption
      nonce. The nonce MUST NOT be reused in different sessions.

New paragraph in the Security Considerations section
Proposed:
Security considerations about HPKE are addressed in RFC 9180. Security
considerations about PDM are addressed in RFC 9250. Security considerations
about destination objects are addressed in RFC 8200.