ECDH-1PU is a C(1e, 2s) key agreement scheme (as per SP800-56A) that is meant to be non-interactive through its use of the "one pass unified" model.
As such, it cannot guarantee the following to the receiving party:
Key Freshness (e.g. that the key material is independent from previous key material, since the recipient didn't contribute anything to it and we don't have a mean to check it was properly generated in the key wrapping case)
Forward Secrecy
Backward Secrecy
Key Compromise Impersonation resilience (already discussed in ECDH-1PU section 4)
To see how backward and forward secrecy is easily compromised, it is sufficient to study the aftermath of a compromise of the receiver's static key.
I think this is currently not properly covered in the "Security" section of the ECDH-1PU spec, as only the KCI resilience is really discussed here. But in my opinion it might be valuable to add details to the spec to prevent people from having wrong ideas wrt. the security guarantees of ECDH-1PU.
Proposal:
add a couple paragraph to cover key freshness and backward/forward secrecy in the section 4 of the spec.
ECDH-1PU is a C(1e, 2s) key agreement scheme (as per SP800-56A) that is meant to be non-interactive through its use of the "one pass unified" model.
As such, it cannot guarantee the following to the receiving party:
To see how backward and forward secrecy is easily compromised, it is sufficient to study the aftermath of a compromise of the receiver's static key.
I think this is currently not properly covered in the "Security" section of the ECDH-1PU spec, as only the KCI resilience is really discussed here. But in my opinion it might be valuable to add details to the spec to prevent people from having wrong ideas wrt. the security guarantees of ECDH-1PU.
Proposal:
WDYT?