Marco,
Fine. You and the wg are the experts, and I'm just a kibitzer.
I've asked the question, and you have considered it. That is what the
genart review is for.
Best wishes,
Paul
On 9/10/25 1:46 PM, Marco Tiloca wrote:
Hi Paul,
Thanks for the discussion and input.
We agree and we don't have specific examples with hard needs.
While not ruling out possible cases altogether, we are actually not
introducing any additional limitations, and the current text is also the
result of a previous review comment.
So we prefer to use the latest proposed formulation, where the second
paragraph of Section 2.6.2 is trimmed down to keep only its first two
sentences.
Thanks,
/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:* Tuesday, September 9, 2025 7:29 PM
*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
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
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
