Hello Paul, Thanks for the follow-up comments.
We have been addressing your latest points in a new Github branch at [1]. Please see inline below the specific commits addressing each point. Best, /Marco [1] https://github.com/ace-wg/ace-key-groupcomm-oscore/tree/ad-review-2 ________________________________ From: Paul Wouters <[email protected]> Sent: Thursday, September 11, 2025 3:52 PM To: Francesca Palombini <[email protected]> Cc: Ace Wg <[email protected]>; Marco Tiloca <[email protected]> Subject: Re: AD review of draft-ietf-ace-key-groupcomm-oscore-17 On Thu, Aug 28, 2025 at 8:32 AM Francesca Palombini <[email protected]<mailto:[email protected]>> wrote: Thank you very much for the in-depth review, and apologies for the delayed response. We have submitted a new version that should hopefully address all your comments. Thanks for the extensive response! I've cut all the things we agreed on. > Section 6 > > > it is RECOMMENDED to use an 8-byte long random nonce. > > Can 8 zero bytes be used? I assume not? So perhaps this needs to > say a little bit more? Or perhaps this RECOMMENDED is a MUST ? We are not sure to understand the comment. I was not sure whether the RECOMMENDED bound to "8 bytes" or "random bytes or "8 random bytes" and what would be "not recommended but still acceptable". Normally nonces are a security thing and there is a minimum requirement. Eg if you say: It is RECOMMENDED that the random nonce is at least 8 bytes Then the random part is a requirement, and one cannot use 8 zero bytes all the time. Your above text does not make it clear if the implementation cannot always use 8 zero bytes (not recommended but still okay) Since the nonce is randomly generated Is it? Or is it only RECOMMENDED? :) If the question is more about recommended size of nonces, those implications are discussed in the security considerations (see Section1 15.2). So perhaps my phrasing above is better then? ==>MT Addressed at https://github.com/ace-wg/ace-key-groupcomm-oscore/commit/1e236bf14db0d92913663e7939e57b48532d20f7 <== > > In order to prevent the acceptance of Ed25519 and Ed448 > > public keys that cannot be successfully converted to > > Montgomery coordinates, and thus cannot be used for > > the derivation of pairwise keys (see Section 2.5.1 of > > [I-D.ietf-core-oscore-groupcomm]), the Group Manager MAY reply > > with a 4.00 (Bad Request) error response in case all the following > > conditions hold: > > Why is this a MAY and not a MUST ? Because, even if the group uses the pairwise mode, that specific joining node might not support the pairwise mode or might not plan to use the pairwise mode in the group, which is fine. Can that not be clearly indicated? Instead of the MAY, it would be better to state these differences? In such a case, unless the Group Manager is strict about that, the joining node will still be able to join the group and to use the group mode for sending messages protected with the group mode, signing those with its EdDSA private key, even though the corresponding public key is not eligible to be converted to Montgomery coordinates. Perhaps something like "If the Group Manager is enforcing [technobabble], it MUST send 4.00 (Bad Request)". ==>MT Addressed at https://github.com/ace-wg/ace-key-groupcomm-oscore/commit/a1d482e4abcee2f98a81f446d86b2eeb35203d81 <== However, your comment made us notice that this same handling should have happened also for the POST handler in Section 9.4 "Upload a New Authentication Credential", so we have added a bullet point to cover that. [ed01b52](https://github.com/ace-wg/ace-key-groupcomm-oscore/commit/ed01b52) > > The 'cnonce' parameter MUST include a new dedicated nonce N_C > > generated by the joining node. > > Is the Group Manager supposed to track this to enforce? If so, perhaps > explicit text for that should be added or else implementers won't enforce > this. The Group Manager is not supposed to explicitly check whether the new N_C is different from the previous one or not. It is in the interest of the Client to use a different N_C, in order to "salt" in a different way the computation of the proof-of-possession evidence for its own authentication credential and for the Group Manager's. Then maybe a MUST should be avoided here? I am thinking of an implementer that needs to justify with code and testcase every MUST, and you seem to indicate here that this MUST would have no code or test case since the Group Manager isn't supposed to check the freshness of the nonce? Maybe "the 'cnonce' parameter is expected to include a new ......" (but not a hill for me to die on) ==>MT Addressed at https://github.com/ace-wg/ace-key-groupcomm-oscore/commit/44063acb91b1652bc59ffa642e7dd6421724146f <== As these are all minor points and not blockers, I have started the IETF LC. Paul
_______________________________________________ Ace mailing list -- [email protected] To unsubscribe send an email to [email protected]
