Early Review of draft-ietf-ippm-encrypted-pdmv2-04
review-ietf-ippm-encrypted-pdmv2-04-secdir-early-lonvick-2023-08-12-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 NOT READY.

I think that the authors are on the right track with the encryption scheme and
its implementation. However, the draft lacks the necessary RFC 2119 and 8174
language to properly define the requirements for interoperability. It also has
a lot of unnecessary information that is not fully aligned with current
practices and is confusing.

Section 5.4 contains the Cryptographic Algorithm. To maintain interoperability,
all implementations must use the same algorithm or be given the opportunity to
choose among offered algorithms. In this case, the specification only provides
the reasons why the selected algorithm was chosen - it does not define which
algorithm MUST be used. This just needs to be nailed down.

Guidance should be given on what a receiver should do if the Options Length is
neither of the two provided values. The same goes for if the Vrsn value is not
0.

There is no need to provide any background about RFC 1421 when saying why the
HPKE algorithm was chosen. It's sufficient to just provide the reasons why HPKE
fulfills the requirements. That is to say, that if HPKE provides
confidentiality and integrity that are required by PDMV2, then just say so.

It may be beneficial to write up a very brief threat model in the Security
Considerations section and address that. Most of that is already written in the
draft so it shouldn't take much effort. The needs for integrity and
confidentiality are already defined. It appears that denial of service through
resource exhaustion is also a concern. The latter may be addressed by
RECOMMENDING that real-time decryption and analysis not be done. The reasons
for RECOMMENDING that real-time decryption need not be done may be explained in
the Security Considerations section. The authors may wish to consult RFC 3552
(BCP 72) on how to write up a limited threat model.

Section 3, Terminology, contains several definitions. It appears that the
authors are trying to be helpful to the reader by providing some background
information. Unfortunately, not all of these definitions are consistent with
the current usage. For example, I've not seen that a symmetric key need be a
"uniformly random bitstring". If the authors wish to provide some guidance,
they may reference RFC 4949, which provides some guidance on terminology.

Nits:

I believe that the authors should be saying that the PSNTP and the Global
Pointer should be incremented sequentially rather than monotonically. (I just
submitted an errata report noting the same for RFC 8250.)

The term "DOH" is used but not defined. I'm assuming it's the DO Header.

Section 8 is "Privacy Considerations" and it only states that privacy is
achieved through encryption. It may be better to describe how confidentiality
is achieved since that's the security goal presented in Section 5.

Best regards,
Chris