Thanks to Marc Blanchet for the ARTART review.

I agree with his comments.

I think the appendix section A.2 should probably be removed.

If it is necessary to specify the details of HPKE more concretely, that should be done in the body of the document.

I also agree with Roman's DISCUSS on mandatory to implement algorithms and HPKE.

### Discuss

HPKE has a PSK Mode (and AuthKEM Mode), but this document does not mention which modes of HPKE are supported.

It was not obvious to me how the salt and nonce values are used.

Typically HPKE supports auxiliary application information using info and aad:

https://datatracker.ietf.org/doc/html/rfc9180#name-auxiliary-authenticated-app

I see this sentence:

Encrypted PDMv2 has most of the metadata fields encrypted except for PSNTP which is also used as a nonce in HPKE AEAD.

I would suggest explaining exactly what you are setting the value of "info" and "aad" too, and perhaps include some test vectors.

This document is not ready and needs to justify its use cases and implementation
choices much better. When it folds in encryption schemes, it needs to document
exactly what bytes go over the wire for establishing the security contexts between peers.

Details follow below.



        Inferring from the PDM data, the attack can launch a timing attack.
        For example, if a cryptographic protocol is used, a timing attack may
        be launched against the keying material to obtain the secret.
         
Can't the attacker already infer these from the packet stream, even without PDM data?

        PDM metrics may also help the attacker find out about the network
        speed or capabilities of the network path.  For example, are there
        delays or blockages?  Are there alternate or multiple paths?
        
Similarly here, doesn't the attacker already infer this based on timing of the packets?

        
In fact, RFC 8250 in The Security Considerations says this too:

        Let us discuss fingerprinting of the end host first.  It is possible
        that seeing the pattern of deltas or the absolute values could give
        some information as to the speed of the end host -- that is, if it is
        a very fast system or an older, slow device.  This may be useful to
        the attacker.  However, if the attacker has access to PDM, the
        attacker also has access to the entire packet and could make such a
        deduction based merely on the time frames elapsed between packets
        WITHOUT PDM.


The remaining part of 8250's Security Considerations mostly talk about
revealing the application, which the port reveals as well, so now this
concern would apply only to v6 IPsec packets?

Second, wouldn't adding encryption of data significantly modify the timings so
that performing the measurements would invalidate the measurements ?

Section 3

The encryption is not specified. How is this done? Which kind of key exchange
is used? If so, how would this key exchange affect the measurements? Also, if
doing a key exchange anyway (eg tls or ike) why not just use ike/ipsec or tls
and protect the entire stream data. This would also hide the port, which also
fingerprints the application used?


Section 3.3

I don't understand how the unencrypted and encrypted length can be the same size?
Unless something like a one time pad is used.

Section 5

Why use HPKE together with another key exchange to prove identities? If you use
TLS or IKE, you already basically end up with a shared key. This can be used
with a simple KDF to create keying material. I don't understand why the setup
with yet another private/public key with HPKE is needed. Key Exchanges are
very expensive, far more than encryption/decryption or hashing/KDF operations.

        Alternatively, the network administrator might choose to create a
        policy that prohibits the use of PDM or unencrypted PDMv2 on their
        network.  The implementation SHOULD provide a way for the network
        administrator to enforce such a policy.

If 8250 does not provide a method for this (and I don't see it does),
this SHOULD does a lot of work.  It basically Updates: 8250 but without
providing a specification on how it actually modifies the IPPM protocol.

        If a client sends a packet with a PDM option which does not match the
        network policy, then the PDM option MUST be ignored and processing
        continue normally.

How does the server know this network policy?

Section 6:

        As discussed in the introduction, PDM data can represent a serious
        data leakage in presence of a malicious actor.

I don't think it did show "serious data leakage". In fact, 8250 considers it
not serious. See my reasoning above.


        An implementation SHOULD attempt to detect if PDM data is forged or
        modified by a malicious entity.

How could it do this? Can you describe this in steps that an implementer could
use to detect this?


        An unauthorized party MUST NOT be able to send PDM data and MUST NOT
        be able to authorize another entity to do so.

How could it do this? Can you describe this in steps that an implementer could
use to detect this?

Section 6.4

I believe it is misunderstood when HPKE should be used, and when regular key
exchanges which authenticate and setup an encryption key should be used. The
use case for HPKE has a lot more to do with creating groups of participants
that share a symmetric key, and is not used for 1-on-1 peer exchanges.

Section 7

I don't think this section is written properly. It should be about the security
considerations of the specification. Instead if seems to be clarying the use
case for the specification, something it already did in the introduction.

        attackers with the ability to intercept packets can conduct passive attacks

"intercept" is an unclear word to use for a passive capability. Intercept can mean
"prevent delivery" as well as "see while in transit".

         In these cases it is suggested to use IPSec ESP [RFC4303]
         in tunnel mode (in which case the PDMv2 can be used unencrypted).

Indeed, this also protects the protocol and port numbers. The case for encrypted PDMv2
is therefor very weak.


        A direct consequence of modifying the performance data could be,
        for example, to hide an ongoing QoS violation, or to create
        a fake QoS violation, with consequences on the violation of
        Service Level Agreements.

If you have an attacker in your network that can modify packets, the cited
issues are the least of your concern? In fact, your authorized endusers
can do the exact same thing as these attackers.

If an attacker can insert or delete packets on your network, again performance
measuring seems to be the least of your concern. Note that dropping or inserting
packets would also disrupt TCP streams and UDP applications that use their own
sequence numbers to detect packet loss or duplicates.

IANA Considerations

I would expect an encrypted version of PDM to use a new option in the
"Destination Options and Hop-by-Hop Options" registry, and not re-use
the 0x0F value for unencrypted PDM. Why was it decided not to make this
clear distinction?