Draft: draft-ietf-ppm-dap

Commentary: Specifically : Specify use of the " one - shot " HPKE APIs defined in RFC9180 , replacing equivalent use of the " multi - shot " APIs . ( This change is intended to be a clarification , not a functional change . ) Move the task_id parameter from the " info " parameter to the " aad " parameter . This is intended to protect against key - commitment - related attacks[1 ] . ( This is a functional change . ) Clarify that the field is an encapsulated key , rather than an encryption context . ( This is a clarification , not a functional change . ) [ 1 ] See discussion in 
 Per section 8.1 : PPM effectively uses the single - shot APIs ; we should consider refactoring PPM 's usage of HPKE to use only one of applicationinfo & AAD . Following the advice of the HPKE RFC , we would want to use application_info . This would permit slightly simpler implementations . I am not sure how much it would simplify the HPKE computations . 
 Should we then formally use the single shot HPKE APIs from ? 
 That would be my recommendation ( though , somewhat confusingly given the advice quoted above , those APIs still allow specifying both application info & AAD ) . Implementations can & do already use the single - shot APIs , so I strongly suspect specifying the single - shot APIs will be feasible . & . ] 
 +1 to using single - shot APIs , though I 'm not sure I agree that using either info or add ( but not both ) is simpler . What 's the reasoning ? 
 The reasoning is : a ) it follows the advice of the HPKE spec ( quoted above ) b ) AFAICT , in a single - shot setting , application info & AAD serve exactly the same purpose , so using both is arbitrary / confusing / a potential source of mistakes . ( in a multi - shot setting , application info is bound to all encryptions / decryptions done by the same context ; AAD is bound to a single encryption / decryption ) 
 TBH I 'm not sure I agree with the quoted guidance here . There is a concept in protocol design known as " domain separation " , the goal of which is to provide some kind of binding of long - term secret key operations to the context in which they were used . Imagine , for example , that someone used an HPKE secret key for PPM and some other protocol . Suppose further that both are using the empty string for . Then the security of our PPM deployment depends on how the other protocol uses the derived AEAD key , since in both protocols may end up deriving the same AEAD key . One way to avoid creating this attack surface is to pick an string that no other application is likely to choose so that derived keys are guaranteed to not collide ( except with some negligible probability ) . That said , I 'd go for changing how we use and . Something like this might be simpler : Let be a fixed string that identifies the protocol . It would be good if this string were relatively long , say the SHA-256 hash of " ppm-00 " . Let encode the task ID , sender / receiver roles , etc . 
 I definitely agree that application info should include information allowing domain separation , for the reasons you mention . ( Indeed , the current PPM spec includes the strings " ppm input share " or " ppm aggregate share " in its application infos , presumably for this purpose . ) But I think that 's orthogonal to the question of whether we should also use AAD , since the application info could also include information other than the " domain separation parameter " . Picking one example to make things concrete , a client upload request sets its application info to and its AAD to . But it could just as easily set the application info to ( i.e. the concatenation of the two previous strings ) and not use AAD . ( Or alternatively , it could place that string in the AAD and not use application info . ) My argument is that it 's simpler to use only one of the parameters , since in the single - shot setting that PPM is using HPKE , the two parameters serve exactly the same purpose ( i.e. including additionally - authenticated data ) . 
 As I see it , our goal is to make sure that decryption only succeeds if the sender and receiver agree on the " context " , i.e. , the task ID , sender / receiver role , nonce , extensions , and so on . This way a MITM can not force the aggregator to interpret an input share incorrectly . Does this sound reasonable to you ? From the point of view of this threat model , I do n't think it 's immediately clear that sticking the context in or is equivalent . For example , if we stuff the context in , then it influences the derivation of the AEAD key ; but depending on the AEAD , it might be feasible for an attacker to find a find two keys that decrypt the same ciphertext . ( See ) More analysis will be needed to say for sure whether this weakness in the AEAD amounts to an attack against our protocol . In the meantime , sticking the " context " in seems like a more conservative choice to me . 
 Given your concern , your approach SGTM . It sounds like this may be a concern worth raising with the folks working on the HPKE spec , given the advice to " use the Setup info parameter for specifying auxiliary authenticated information " , but I 'm not going to chase this down currently . 
 So I think there 's two tasks for this issue : Move task ID from to Use single - shot APIs for HPKE Anything else ? 
 Yep , I think that 's it . 
 ( reopening for now as the fix PR has been reverted temporarily ) 
 Perfect , great work !
Paragraph (version A):
where "pk" is the aggregator's public key and "server_role" is the
Role of the intended recipient ("0x02" for the leader and "0x03" for
the helper).  In general, the info string for computing the HPKE
context is suffixed by two bytes, the first of which identifies the
role of the sender and the second of which identifies the role of the
intended recipient.
Paragraph (version A):
where "input_share" is the aggregator's input share and "nonce" and
"extensions" are the corresponding fields of "Report".  Clients MUST
NOT use the same "enc" for multiple reports.
Paragraph (version B):
where "pk" is the aggregator's public key; "server_role" is the Role
of the intended recipient ("0x02" for the leader and "0x03" for the
helper); "task_id", "nonce", and "extensions" are the corresponding
fields of "Report"; and "input_share" is the aggregator's input
share.
Paragraph (version A):
where "sk" is the HPKE secret key, "task_id" is the task ID, "nonce"
and "extensions" are the nonce and extensions of the report share
respectively, and "server_role" is 0x02 if the aggregator is the
leader and 0x03 otherwise.  If decryption fails, the aggregator marks
the report share as invalid with the error "hpke-decrypt-error".
Otherwise, it outputs the resulting "input_share".
Paragraph (version B):
where "sk" is the HPKE secret key, and "server_role" is the role of
the aggregator ("0x02" for the leader and "0x03" for the helper).  If
decryption fails, the aggregator marks the report share as invalid
with the error "hpke-decrypt-error".  Otherwise, it outputs the
resulting "input_share".
Paragraph (version A):
where "pk" is the HPKE public key encoded by the collector's HPKE
key, and server_role is is "0x02" for the leader and "0x03" for a
helper.
Paragraph (version A):
where "sk" is the HPKE secret key, "task_id" is the task ID for a
given collect request, and "server_role" is the role of the server
that sent the aggregate share ("0x02" for the leader and "0x03" for
the helper).
Paragraph (version B):
where "pk" is the HPKE public key encoded by the collector's HPKE
key, "server_role" is "0x02" for the leader and "0x03" for a helper.
Paragraph (version B):
where "sk" is the HPKE secret key, "task_id" is the task ID for the
collect request, and "server_role" is the role of the server that
sent the aggregate share ("0x02" for the leader and "0x03" for the
helper).