Draft: draft-ietf-ppm-dap

Commentary: GitHub seems to think there 's a conflict on the other PR , but I do n't see it on the branch , so this just cherry - picks all changes from that PR . 
 HPKE is parameterized by several different configuration choices ( defined in , 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 : Should PPM seek to specify HPKE configuration parameters at all ? 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 " ) 
 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 do n't know if we 'll need this sort of agility for PPM . My $ 0.02 : We probably will need to eventually . There is a notion in IETF standards known as " mandatory to implement ( MTI ) " ciphersuites . We might consider defining MTI suites for HPKE , but I do n'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 ) . 
 I would recommend specifying a MTI suite while allowing other suites as needed for particular deployments , just .
Paragraph (version A):
"collector_config": The HPKE configuration of the collector
(described in hpke-config).
Paragraph (version B):
"collector_config": The HPKE configuration of the collector
(described in hpke-config); see compliance for information about
the HPKE configuration algorithms.
Paragraph (version B):
Before the client can upload its report to the leader, it must know
the HPKE configuration of each aggregator.  See compliance for
information on HPKE algorithm choices.
Paragraph (version A):
Note: Long cache lifetimes may result in clients using stale HPKE
keys; aggregators SHOULD continue to accept reports with old keys for
at least twice the cache lifetime in order to avoid rejecting
reports.
Paragraph (version B):
Note: Long cache lifetimes may result in clients using stale HPKE
configurations; aggregators SHOULD continue to accept reports with
old keys for at least twice the cache lifetime in order to avoid
rejecting reports.