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