Hi Barry,
Thanks for your review.
On Fri, Aug 08, 2025 at 09:12:16AM -0700, Barry Leiba via Datatracker wrote:
> A small point: The abstract seems more detailed than is necessary
> for an abstract. I would shorten it and allow the introduction,
> which the abstract currently repeats, to stand as the more detailed
> version. But if you like it as it is, please just ignore this
> suggestion.
>
> SUGGESTION
> The Resource Public Key Infrastructure (RPKI) makes use of signed
> objects called manifests, each of which includes a "manifest
> number”. This document updates RFC9286 by specifying issuer and
> RP behaviour when a manifest number reaches the largest possible
> value, a situation not considered in RFC9286.
> END
We agree that the existing abstract is too detailed, and have updated
it per your suggestion.
> It’s not obvious that Section 2 makes the updates to 9286 until one
> reads the first sentence of Section 3. I have two suggestions,
> either of which should make it clearer:
>
> 1. Change the title of Section 2 to something like “Manifest Number
> Handling: Update to RFC 9286”.
>
> 2. Add a one-sentence paragraph to the beginning of Section 2 that
> says something like, “This Section updates [RFC9286] for the
> handling of manifest numbers.”
We had a separate comment from another reviewer along these lines, and
updated the first paragraph of section 2 to have an additional
sentence at the end:
This is an update to the requirements set out in section 4.2.1 of
RFC9286.
which we think also addresses the point you are raising here.
> The last sentence of Section 2 says, with regard to RFC 8488, “The
> approach set out in the current document is different from that
> approach.” It’s not clear to me whether “the current document”
> means “this document” (I think that’s what you mean) or RFC 9286. I
> suggest replacing that phrase with one or the other to make it
> explicit.
Updated to "this document".
> Question for the Security Considerations: Is it possible for an
> attacker to force a “largest value” situation and take advantage of
> that to falsify a route? If the situation can only be created
> internally by the CA, that in itself is worth mentioning, to make
> that robustness clear.
The short answer is "no", so we don't think an update is required for
this, but see below for more detail.
At least in a conventional setup, TA manifest reissuance is something
that happens infrequently (e.g. monthly) and is not a function of
subordinate CA activity, so an attacker would need to have some sort
of unusual access to the manifest issuance system in order to set the
manifest number as the largest possible value. Even if an attacker
had that sort of control, the RPs available today fall into one of the
following two categories:
- does not check for manifest number regressions (i.e. changing the
manifest number to a lower value causes no problems); or
- does check for manifest number regressions, but supports changing
the filename in order to reset the recorded manifest number for the
CA (i.e. it supports the behaviour described in this document).
So once the attacker had issued that manifest, the TA could rectify
the situation very easily. Even during the window of time in which
the manifest with the largest possible manifest number is the
available manifest, there is no ability on the part of the attacker to
falsify a route, because the actual RPKI objects used by RPs remain
the same after that change.
If the manifest expires without the TA changing the filename and
resetting the manifest number, then RPs will operate as though the TA
doesn't exist, and at least in theory an attacker could take advantage
of this situation to falsify a route, due to the absence of the
protection offered by RPKI. For all RPs except OctoRPKI, that problem
can be rectified very easily, by changing the filename and resetting
the manifest number. For OctoRPKI, resynchronisation is not supported
in this case, and operators have to manually reset the state in order
to get it to resynchronise for the affected TA. However, OctoRPKI's
last release was in April 2023, and it has been formally deprecated
since June 2024. Also, such a scenario would only arise where the
attacker can also change the expiry date on the manifest such that the
manifest is very short-lived, since in a conventional setup the
manifest is long-lived (e.g. one month or longer), and the TA or one
of the RPs for the TA would notice prior to expiry the problem with
the use of the largest manifest number.
-Tom
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
