Re: [Sidrops] WG Adoption call for draft-harrison-sidrops-manifest-numbers-01 - ENDS 04/15/2024 (April 15 2024)

[Ben Maddison <[e-mail]>]

Hi all,

I support this adoption.

Some thoughts on the conversation so far...

On 04/03, Tim Bruijnzeels wrote:
> Hi,
> 
> > On 2 Apr 2024, at 18:35, Job Snijders <job=[e-mail]> wrote:
> > 
> > Dear Tim, WG,
> > 
> > On Tue, Apr 02, 2024 at 01:45:59PM +0200, Tim Bruijnzeels wrote:
> >
> > [snip]
> >
> > Thank you for sharing your thoughts, I think it is good to discuss and
> > document our choices in the SIDROPS mailing list archives. I think there
> > are three compelling reasons not to use serial number arithmetic in this
> > particular context:
> > 
> > 1) The algorithm presented by RFC 1982 ("Serial Number Arithmetic") has
> >   a significant shortcoming: there are sequence numbers for which
> >   comparison is undefined. A potential solution is to use signed two's
> >   complement binary arithmetic operations to workaround this shortfall,
> >   this implies serial numbers of a bit-length matching the machine's
> >   integer sizes (usually 32 or 64 bit), but in the RPKI we're dealing
> >   with 159-bit serials... I consider arithmetic operations on a number
> >   space this large an unwelcome complication to be avoided if possible.
> > 
> > 2) As you (Tim) point out: "RPs may not see it if another update follows
> >   shortly after". Indeed, depending on all RPs seeing the initiation
> >   and subsequent steps of the arithmetic trick seems fragile to me. 
> > 
> >   RFC 1982 section 7 states:
> > 
> >      "If this [red: a decrease] must be done, then take special care to
> >       verify that ALL servers have correctly succeeded in following the
> >       primary server's serial number changes, at each step."
> > 
> >   The type of verification RFC 1982 refers to is not possible in the
> >   RPKI, as a CA can't query RPs whether they have correctly succeeded
> >   in following the manifest's serial number changes.
> 
> Yeah, sure, but we could still think about a reset to a low number if the
> number exceeded large some number. This being applicable to TA manifest
> they are typically not republished frequently. E.g. a TA could only be allowed
> to reset after a manifest has been out there for a while, like days or weeks,
> or even months.
> 
> If this is to be more generally applicable to CAs (rather than forcing them
> to do the key rollover mentioned) then this is probably not possible.

I'm not inclined to special-case TAs unless we absolutely have to.

Making the assumption in 2024 that TAs won't begin republishing daily in
2025 also seems fragile to me.

> > 3) Speaking from my own experience with the rpki-client implementation,
> >   the code paths which open a previously cached manifest and a
> >   purported new manifest along side each other, adequately validate &
> >   compare these two objects, and finally select one of the two;
> >   - already today - are amongst the most complicated pieces of code we
> >   have to maintain. I am very hesitant to add more complications (such
> >   as outlined above in reason 1) to this part of the code base beyond
> >   what's already there.
> > 
> > My gut feeling is that 'filename change effectively results in serial
> > numer reset' is easier to implement and easier to explain, than a
> > RFC1982-based approach; having said that, I do recognize it certainly is
> > not the only possible approach.
> 
> Ok, my concern is not blocking. If this is the way that current RP implementers
> want to go that is fine by me (other RP implementers, opinions?).
> 
> But just to explain where my dislike of names comes from:
> 
> I don’t implement an RP today, but I was part of the team that implemented
> one many years ago (see RFC 8488). This implementation intentionally separated
> RPKI object fetching and validation, and did not rely on names. (and later
> versions of that software also used asynchronous fetching of objects to prevent
> blocking validation on bad repos). The reason for not relying on names was
> that this would help to make validation URI and transport agnostic - allowing
> for different mechanisms and possibly even mirroring in future.
> 
> Using names as an identifier in the way this I-D proposes complicates that
> approach a bit. Then again, it seems that all other RP implementations just
> use names as stable identifiers. So, this probable is not an issue to them.

Having some identifier for signed objects that it stable across key and
content changes is valuable for the purposes of tracking structural
changes to the system over time.

The fact that all we have for this purpose today is an rsync URI is less
than ideal, but we knew that already! I don't think this document is the
place to patch that shortcoming.

My initial reaction on first reading the draft was "ick, that seems like
a bit of a smell", but on reflection, I tend to agree that it's probably
the right approach.

Cheers,

Ben