On Mon, Dec 16, 2024 at 10:06:05PM +0000, Job Snijders wrote:
> Dear all,
> 
> The RPKI ecosystem suffers from a partially unmitigated risk related to
> long-lived Trust Anchor certificate issuances.
> 
> For this to make sense, don't confuse certificates and keypairs! TA
> keypairs (and TALs) are expected to be very long-lived and are to be
> used periodically to issue new instances of (shorter-lived) TA
> certificates.
> 
> Issues could arise when a on-path attackers (or operational errors such
> as restoring a webserver's data from too old an backup) bring back into
> circulation old (but still valid) TA certificate. Older certificates
> remain valid for the duration of their validity period, because TA
> certificates - being top of the chain - cannot be revoked.
> 
> Here I shared real world examples of potential replayable certificates.
> Old problematic TA certificates that - today - still would pass validation:
> https://mailarchive.ietf.org/arch/msg/sidrops/NxzvSFH0sPXEmyfOS99cLApFKqM/
> 
> The trouble with these replayable TA certificates is that when an
> on-path entity ends up presenting such an outdated-but-still-valid
> certificate to the RP, it's acceptance would damage the RP's local
> validated cache. Parts of the validated output will disappear, in an
> unpredictably manner.
> 
> Periodic reissuance is important because TA certificates are not
> entirely static, which of course is why replay might even be an issue in
> the first place!. There are 3 'dynamic' fields in TA certificates:
> 
>   - the validity period (notBefore, notAfter)
>   - the SubjectInfoAccess (where can the RP find the first repository?)
>   - the extensions for IP addresses & AS identifiers (RFC 3779 INRs)
>     (the RFC 3779 extensions are of critical importance to the
>     RPKI's chain validation algorithm)
> 
> RIRs will want RPs to validate using the 'latest' issuance of the TA
> certificate, because a TA cert from 10 years ago obviously will be 10
> years behind on operational decisions, potential SIA migrations,
> resource transfers, new IANA assignments, or any other updates to the
> RIR's current holdings.
> 
> So how do we make good on this situation again? (knowing the 100 year
> certs can't be revoked) Preferably without all RIRs having to rekey &
> redistribute new TALs?
> 
> The plan to overcome this risk has three steps:
> 
> step 1) RPs to prefer shorter-lived Trust Anchor certificates over
>         longer-lived ones. (rpki-client already implemented this)
>         https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-ta-tiebreaker
> 
> step 2) RPs ship with scheduled future refusal of ultra long-lived Trust
>         Anchor certificates (that's the below diff).
> 
> step 3) Consequently, RIRs have to reissue shorter-lived TA certificates
>         to avoid being rejected by RPs.
> 
> The end result is that after anno 2026 / 2027, if 100 year or 10 year
> certs somehow be brought back into circulation, RPs will simply refuse
> such long-lived certs, despite them technically being 'valid'.
> 
> Why this works:
> 
> The ta-tiebreaker mechanism provides an incentive for TA operators to
> reissue with reasonable (1 or 2 year) validity periods, as those certs
> will be preferred. In turn, RPs scheduling refusal of long-lived certs
> at a predetermined future point in time, relieves TA operators from
> worrying about previously issued certs with ultra long lifetimes. It is
> a win win for everyone in the ecosystem.
> 
> Scheduling details:
> 
> I picked February 2nd 2026 for phase 1, because 02-02-2026 and
> 02-02-2026 are unambiguous dates in both the US and elsewhere. I picked
> March 3rd 2027 for phase 2, because 03-03-2027 also is unambiguous and
> visually is very distinct from 02-02-2026.
> 
> My hope is that a schedule like this will make global coordination less
> error-prone, I also wouldn't want to impose undue burden forcing TA
> operators to reissue at short notice without adequate preparation time.

I support all of the above. I also think it is good if the TA operators
exercise the key ceremony to issue new certs.

> The below was joint work with tb@
> 
> Thoughts? OK?

The implementation is god-awful, but I can't think of a better way.

ok tb