[Gen-art] Re: Gen-ART Last Call review of draft-ietf-core-oscore-groupcomm-26

[Paul Kyzivat <[e-mail]>]

Marco,

Just a couple of follow-up comments.
I've trimmed out the stuff that is settled,
and I marked by new comments below with "==>PHK"

On 9/8/25 11:30 AM, Marco Tiloca wrote:
> Hi Paul,
> 
> Thanks for the follow-up! Please see our replies inline, marked as 
> "==>MT_2".
...
>  > 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.
...
> ==>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 "largestusable 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?

==>PHK

Yes. But see below.

...

>  > 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.

==>PHK

ISTM that comparing an SN to the bounds of a window is effectively doing 
subtraction, which requires comparable arithmetic to incrementation.

It isn't hard to do arithmetic on 40-bit integers, even on a machine 
with only hardware support for 32-bit (or 16 or 8-bit) integers. So I 
still fail to understand why you need to offer the option to limit the 
range. But if you do, then your suggestion above seems ok.

	Thanks,
	Paul