Hi Marco,
Thanks for addressing my comments. Most seem fine to me, with a couple
of exceptions. See below for more discussion.
Thanks,
Paul
On 9/5/25 5:15 PM, Marco Tiloca wrote:
1) ISSUE
Section 2.6.2 says:
"If an implementation's integers support wrapping addition, the
implementation MUST treat the Sender Sequence Number space as exhausted
when a wrap-around is detected."
I think I understand the issue, but question how it is stated. Just
because the implementation does wrapping addition on integers shorter
than 40 bits, that doesn't mean the implementation isn't capable to
doing proper 40 bit arithmetic. There must be a better way to say this.
Perhaps:
"An implementation must treat the Sender Sequence Number space as
exhausted when the Sender Sequence Number approaches the maximum value
it can properly increment."
Also, if an implementation has difficulty handling 40 bit integers,
won't that also be a problem if it *receives* big sequence numbers?
==>MT
Thanks for raising this detail. We have rephrased as below.
OLD
> If an implementation's integers support wrapping addition, the
implementation MUST treat the Sender Sequence Number space as exhausted
when a wrap-around is detected.
NEW (emphasis mine)
> If an implementation's integers support wrapping addition, the
implementation MUST treat the Sender Sequence Number space as exhausted
when a wrap-around is detected **upon incrementing the value that has
been used as Partial IV**.
This doesn't address my issue. The remedy (treat the Sender Sequence
Number space as exhausted) is fine. The explanation of the circumstances
when it should be applied still seem off the point.
I'm not clear what "implementation's integers support wrapping addition"
means. Isn't it the converse that is of concern? Namely, if the
implementation is *incapable* of properly incrementing a 40-bit integer?
And, if hardware doesn't support it, why can't it be done is software? I
think it is probably a matter that the implementation may *choose* to
limit the sequence number space to less than 40 bits for its own
convenience. (Presumably to some more common size, like 32 or 31 bits.)
The reason why need not be specified.
On the point raised in the last sentence of the comment, that's not
supposed to be a problem. In the OSCORE option value, the Partial IV can
be up to 40 bits, hence a compliant recipient must be able to handle
that if it happens.
That's simpler than the case discussed above, since it does not involve
arithmetic operations or other manipulation of the Partial IV value.
It's just about taking and using the Partial IV value as-is, in order
to, e.g., perform replay checks against a replay window (see Section
5.3), build an AEAD nonce (see Section 5.2 of RFC 8613), or build the
external_aad for processing a message (see Section 3.4).
I certainly don't understand the details, but when the sender includes a
sequentially increasing sequence number in its messages, isn't the
recipient expected to check the sequence numbers of received messages,
and detect missing messages? That seems to also require the ability to
do some arithmetic.
If I am off base here, then never mind.
2) ISSUE
Section 6 says:
"An endpoint MUST be able to distinguish between a Security Context to
process OSCORE messages ... and a Group OSCORE Security Context ... To
this end, an endpoint can take into account ... Alternatively,
implementations can ..."
Why offer alternatives? Why not specify a single unambiguous method?
If there is reason, it would be good to discuss the pros and cons.
==>MT
We have updated the second paragraph of Section 6 "Message Reception" as
below.
OLD
> To this end, an endpoint can take into account the different
structure of the Security Context defined in Section 2, for example
based on the presence of Signature Algorithm and Pairwise Key Agreement
Algorithm in the Common Context. Alternatively, implementations can use
an additional parameter in the Security Context, to explicitly mark that
it is intended for processing Group OSCORE messages.
NEW (emphasis mine)
**The way to accomplish this distinction is implementation specific. For
example**, an endpoint can take into account the different structure of
the Security Context defined in Section 2, **e.g.,** based on the
presence of Signature Algorithm and Pairwise Key Agreement Algorithm in
the Common Context. **Alternatively, at the cost of increasing
storage**, implementations can use an additional parameter in the
Security Context, to explicitly mark that it is intended for processing
Group OSCORE messages.
OK. That makes sense to me.
3) MINOR ISSUE
Section 2.4 says "The authentication credential of the Group Manager
SHOULD be encoded according to that same format."
There is no discussion of what conditions would justify violating the
SHOULD. Without this, many implementers treat SHOULD as MAY. My general
rule is that every SHOULD must specify that alternative.
==>MT
We have clarified by extending the second paragraph of Section 2.4
"Authentication Credentials" as below.
OLD
> The authentication credential of the Group Manager SHOULD be encoded
according to that same format.
NEW
> The authentication credential of the Group Manager SHOULD be encoded
according to that same format, in order to limit the number of formats
that the group members have to support and handle, unless it is
infeasible or impractical for the particular realization or instance of
the Group Manager to have an own authentication credential encoded in
that same format.
That resolves my concern.
4) MINOR ISSUE
Section 7.5 specifies External Signature Checkers. But I couldn't find
any explanation of their purpose.
I leave it to the authors to decide if there ought to be such an
explanation.
==>MT
We have expanded the first paragraph in Section 7.5 "External Signature
Checkers" as below.
OLD
> When a message is protected in group mode, it is possible for
designated external signature checkers, e.g., intermediary gateways, to
verify the countersignature of the message.
NEW
> When a message is protected in group mode, it is possible for
designated external signature checkers to verify the countersignature of
the message. For example, an external signature checker can be an
intermediary gateway that intercepts messages protected in group mode
and ensures that they reach the intended recipients only if it
successfully verifies their countersignatures.
Thanks. Now I get it.
5) NIT
The Abstract uses "CoAP" acronym without expansion. (Its defined in the
Intro.) I think this isn't allowed in abstracts, which often stand
alone. Please expand it in the abstract.
==>MT
We have expanded the first sentence of the abstract as below.
OLD
This document defines the security protocol Group Object Security for
Constrained RESTful Environments (Group OSCORE), providing end-to-end
security of CoAP messages exchanged between members of a group, e.g.,
sent over IP multicast.
NEW (emphasis mine)
This document defines the security protocol Group Object Security for
Constrained RESTful Environments (Group OSCORE), providing end-to-end
security of **messages exchanged with the Constrained Application
Protocol (CoAP) between members of a group, e.g., sent over IP multicast.**
That is good. (That will save you from being called out on it later by
an editor.)
6) NIT: Typo
7) NIT
Thanks.
8) NIT
The IdNits tool reports a number of issues. Many are spurious, but there
are several downrefs that should be evaluated.
==>MT
The included references are as intended and deemed appropriate. Their
understanding and use are required by the present document in a
normative way.
Specifically as to RFC 5869, RFC 6979, RFC 7748, RFC 8032, and RFC 9053,
they are all listed in https://datatracker.ietf.org/doc/downref/
<https://datatracker.ietf.org/doc/downref/>
OK. Its a formality to ensure you have considered it. The question will
be asked again.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
