Hello Paul,
Thanks for your mail! We are actually working on your comments from the AD review and plan to submit a new version of the draft by Monday.
We also wanted to double-check with you about three specific comments, regarding three currently informative references that you believe should be normative instead.
=== Reference to RFC 9176 ===
We agree that this reference should actually be normative.
At the very least, it will remain anyway in Section 2.3, and it should rightly be normative because of that already.
=== Reference to draft-amsuess-core-cachable-oscore ===
(now draft-ietf-core-cacheable-oscore)
This reference is used towards the end of Section 5.1.1 when defining the two configuration parameters 'det_req' and 'det_hash_alg'.
In our opinion, a reader of this ACE document does not need to know how Cacheable OSCORE works. One only needs to know:
- What information is conveyed by the parameters 'det_req' (suggested codepoint: -25) and 'det_hash_alg' (suggested codepoint: -26), which is explained when those are defined in Section 5.1.1 of this ACE document.
- What information is conveyed by the parameters 'det_hash_alg' (codepoint TBD > 0) defined in the CoRE draft and mentioned in Section 6.6.2 of this ACE document. While that parameter is indeed defined in the CoRE draft, Section 6.6.2 of this ACE document is
explaining what the parameter value specifies.
With that in mind, we believe that it should be ok for the reference to the CoRE document to remain informative.
To this end, it is actually better if the three instances "as defined in [I-D.amsuess-core-cachable-oscore]" are rephrased as "(see [I-D.amsuess-core-cachable-oscore])".
If the option above is not ok for you, we can instead remove the reference and the involved text away from this ACE document, and later add that text into the CoRE draft. The text in question consists of the bullet points discussed above, i.e., in Sections
5.1.1 and 6.6.2.
Note that the content mentioned above and using a reference to draft-amsuess-core-cachable-oscore is not a fundamental component of the specification in this ACE document, and it can be placed somewhere else as an extension of what is defined in this document.
Hence, that content can be seamlessly removed, and instead be included in a next version of the CoRE document (now draft-ietf-core-cacheable-oscore), where the add-on use of deterministic requests is defined and to which the parameters above that are currently
in this ACE document pertain.
What do you think?
=== Reference to draft-tiloca-core-oscore-discovery ===
This reference is used in Sections 6.3 and 6.6.
In our opinion, the text after the reference does require to understand this ACE document and the Resource Directory (RFC 9176), but not the specific approach described in the referenced draft-tiloca-core-oscore-discovery.
With that in mind, it might be sufficient to have a less normative-looking text, i.e.:
* In Section 6.3, rephrase as below:
OLD
> The Group Manager can register the link to the group-membership resource with URI specified in 'joining_uri' to a Resource Directory [RFC9176], as defined in Section 2 of [I-D.tiloca-core-oscore-discovery].
NEW (emphasis mine)
> The Group Manager can register the link to the group-membership resource with URI specified in 'joining_uri' to a Resource Directory [RFC9176], **e.g., by using the approach described in** [I-D.tiloca-core-oscore-discovery].
* In Section 6.6, remove the reference altogether, i.e.:
OLD
> If the link to the group-membership resource was registered in the Resource Directory [RFC9176], the Group Manager is responsible to refresh the registration, as defined in Section 3 of [I-D.tiloca-core-oscore-discovery].
NEW
> If the link to the group-membership resource was registered in the Resource Directory [RFC9176], the Group Manager is responsible to refresh the registration.
Following those updates to the text, we believe that it should be ok for the reference to the CoRE document to remain informative.
If the option above is not ok for you, we can instead remove the reference and the involved text away from this ACE document, and later add it into the CoRE draft. The text in question is:
* In Section 6.3, from "The Group Manager can register the link to the group-membership resource with URI specified in ..." until "... directly by the Group Manager, rather than by the Administrator."
* In Section 6.6, from "If the link to the group-membership resource was registered ..." until "... directly by the Group Manager, rather than by the Administrator."
* In Section 6.7, the paragraph "The same considerations as for ... Resource Directory [RFC9176]."
Note that the content mentioned above and using a reference to draft-tiloca-core-oscore-discovery is not a fundamental component of this ACE document, and it can be placed somewhere else where the side-topic of group discovery is covered.
Hence, that content can be seamlessly removed, and instead be included in a next version of draft-tiloca-core-oscore-discovery, which defines one particular approach to use the Resource Directory for registering and discovering (links to) OSCORE groups.
What do you think?
Thanks,
/Marco
Authors and WG,
I do not believe the changes required for the AD review are large. If we can get an updated draft before Monday max, I can still IETF LC it and maybe bring it to a telechat before IETF-125. If we don't reach the IETF LC stage, you will have to wait for
the new SEC AD to get up to speed with ace/lake before this document can move forward. That would be a shame.
Paul
AD review of draft-ietf-ace-oscore-gm-admin-13
Thanks for this document. All in all it is very clear.
I do have some questions and comments/nits:
TLS version
this can rely on DTLS [RFC9147] as per [RFC9202]
Does this mean it requires DTLS 1.3, or is DTLS 1.2 allowed? Should this
be made more explicit?
Default values and their use
While the defaults use RECOMMENDED, things like Section 6.6 state the
value from defaults MUST be used. It is a little unclear to me what
this means when the RECOMMENDED value was not used. Should it use the
different value or the RECOMMENDED to comply to the MUST ?
Fix reference on draft-amsuess-core-cachable-oscore
det_hash_alg refers to draft-amsuess-core-cachable-oscore but this should
be draft-ietf-core-cacheable-oscore.
default values
This section defines the default values that the Group Manager
uses for the configuration and status parameters.
But the next sentence says these are the RECOMMENDED values. So perhaps it
should say that here too?
Section 6.6.1
Why is this listed here? Isn't this regular operation unrelated to this
document?
Section 6.6.2
6.6.2 also repeats this text:
If the value of the status parameter 'active' is changed from true
(0xf5) to false (0xf4):
The Group Manager MUST stop accepting requests for new individual
keying material from current group members
Should this not read that the group members MUST stop sending requests ?
If not, why is this text repeated from 6.6.1? Note that it does say so
in the second bullet point:
* Every group member, upon learning that the OSCORE group has
been deactivated (i.e., 'active' has value false (0xf4)), SHOULD
stop communicating in the group.
then:
Every group member, upon learning that the OSCORE group has
been reactivated (i.e., 'active' has value true (0xf5) again),
can resume communicating in the group.
Am I correct in that group members "learn" this via the pairwise connection
with the GNM by requesting a LIST command filtered by Active state?
Section 6.8
Otherwise, the Group Manager continues processing the request,
I am not sure where this "Otherwise" comes from. Eg if "otherwise" is the
"else" part, what was the "if" part? What part of the processing was done
before this statement was reached?
I wonder if [I-D.amsuess-core-cachable-oscore] should be normative?
[I-D.tiloca-core-oscore-discovery] is definitly normative.
RFC9176 is probably normative too
NITS:
The Constrained Application Protocol (CoAP) [RFC7252] can also
be used for group communication [I-D.ietf-core-groupcomm-bis],
where messages are exchanged between members of a group
I would remove "also" and the comma before "where.
as well as how it should be configured and later on updated
or deleted, e.g., based on the current application state or
pre-installed policies
I had to read this a few times.. how abour "and later on how it should
be updated or deleted"
and is poorly flexible
and is not very flexible.
