|
Hi Paul,
Thanks for the follow-up! Please see our replies inline, marked as "==>MT_2".
Best,
/Marco
Marco Tiloca
Ph.D., Senior Researcher
Phone: +46 (0)70 60 46 501
RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)
Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity
https://www.ri.se
From: Paul Kyzivat <pkyzivat@xxxxxxxxxxxx>
Sent: Saturday, September 6, 2025 12:19 AM To: Marco Tiloca <marco.tiloca@xxxxx>; draft-ietf-core-oscore-groupcomm.all@xxxxxxxx <draft-ietf-core-oscore-groupcomm.all@xxxxxxxx>; core@xxxxxxxx <core@xxxxxxxx> Cc: General Area Review Team <gen-art@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx> Subject: Re: Gen-ART Last Call review of draft-ietf-core-oscore-groupcomm-26 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. ==>MT_2
After some more thinking, we believe that it would actually be better to simply remove the whole sentence "If an implementation's integers support ... when a wrap-around is detected."
The second paragraph in Section 2.6.2 would just be shortened and become as follows:
> Implementations MUST be able to detect an exhaustion of Sender Sequence Number space, after the endpoint has consumed the largest usable value. This may be influenced by additional
limitations besides the mere 40-bit size limit of the Partial IV.
In fact, this should be clear enough already, with no real need to mention integer wrap-around or to delve into details that we do not need to delve into.
Just to clarify what "largest usable
value" means in the retained text: an implementation has to treat the Sender Sequence Number space as exhausted when the latest consumed value SN is equal to (2^40 - 1) or the value (SN + 1) cannot be computed within the sequence number space chosen by the
implementation.
But again, it actually feels unnecessary to include such details in the document.
Does this resolution work for you?
<==
> 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.
==>MT_2
The recipient is not really expected to do that.
Distilling from Sections 7.4 and 3.2.2 of RFC 8613, the recipient has to check whether either of the following holds:
* The sequence number SN in the incoming message was already received, in a message from the same sender that was successfully decrypted and verified. When using the sliding replay window, this is the case if SN falls within the replay window associated with
the sender and is already marked as received. Then, the present message is considered a replay and discarded.
* The sequence number SN in the incoming message it too low. When using the sliding replay window, this is the case if SN is strictly lower than the current lowest value in the replay window, i.e., it falls left of the left edge of the replay window. Then,
the received message is discarded as too old.
So the recipient has to check whether the Partial IV in the incoming messages falls left of the replay window, or within the replay window while having already been consumed, or right of the replay window.
In the latter case, if the message is correctly decrypted and verified, the replay window will "slide to the right". That is, the received Partial IV is set as the new highest value of the replay window, i.e., as the new right edge, and is marked as used. This
is at least the behavior when using by default the anti-replay window used by IPsec AH/ESP and DTLS.
When sliding the replay window to the right, updating its left edge does involve some arithmetic, which is a different topic than the exhaustion of sender sequence numbers on the sender side. If, at a certain point, a recipient can't perform the necessary arithmetic
to update its replay window, then the recipient will have to delete the Recipient Context storing that replay window as not usable anymore.
This protocol inherits the use of replay windows from RFC 8613, so we don't think that these explanations should be included in the document.
<==
> 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://eur05.safelinks.protection.outlook.com/?url=""> > <https://eur05.safelinks.protection.outlook.com/?url="">> 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
