cjpatton
commented
2 years ago PPM currently does not constrain these values, so a specification-compliant PPM implementation may use any set of choices for these values. Different implementations will succeed at interop only if they share a common set of supported HPKE configuration values. This may lead general implementations to support as wide a variety of HPKE parameters as possible, leading to code bloat -- this is especially important in a Web setting.
Another word for "code bloat" here is "cryptographic agility". Agility is problematic for the reasons you mention, as well as others. However it's also often necessary in many cases. For example, lots of TLS implementations prefer X25519 for the key exchange because it's the fastest option, but some deployments are stuck using P-256 for various reasons.
That said, you're right that we don't know if we'll need this sort of agility for PPM.
Questions:
* Should PPM seek to specify HPKE configuration parameters at all?
My $0.02: We probably will need to eventually.
* If so, what are the right parameters to specify? (The best solution might be something like "minimally-compliant PPM implementations must support HPKE configurations X, Y, and Z; implementations may support other HPKE configurations as they wish")
There is a notion in IETF standards known as "mandatory to implement (MTI)" ciphersuites. We might consider defining MTI suites for HPKE, but I don't think this is particularly pressing. Plus, we're likely to have wildly different opinions about what suites are MTI.
Taking a step back, it's completely reasonable for a given implementation of the protocol to have only limited agility or no agility at all. It does impact interop, but in practice there are likely to be a small set of suites that 99% of people implement. For PPM, I would suspect that everyone is going to have (X25519, HKDF-SHA256, AES-GCM).
chris-wood
HPKE is parameterized by several different configuration choices (defined in https://www.rfc-editor.org/rfc/rfc9180.pdf, section 4): a "key encapsulation method", a "key derivation function", and an "AEAD encryption algorithm". The specification goes on to define several options for each of these choices in section 7.
PPM currently does not constrain these values, so a specification-compliant PPM implementation may use any set of choices for these values. Different implementations will succeed at interop only if they share a common set of supported HPKE configuration values. This may lead general implementations to support as wide a variety of HPKE parameters as possible, leading to code bloat -- this is especially important in a Web setting.
Questions: