Contributed by Peter N. M. Hansteen on from the trust the anchors not quite as much dept.
Today Job Snijders (job@) commited code to
rpki-client(8)
to implement a gradual phase in of a stricter policy on TA certificates lifetimes.
The commit message reads,
Subject: CVS: cvs.openbsd.org: src From: Job Snijders <job () cvs ! openbsd ! org> Date: 2024-12-18 16:38:40 CVSROOT: /cvs Module name: src Changes by: job@cvs.openbsd.org 2024/12/18 09:38:40 Modified files: usr.sbin/rpki-client: cert.c Log message: Schedule future rejection of ultra long-lived TA certificates The RPKI ecosystem suffers from a partially unmitigated risk related to long-lived Trust Anchor certificate issuances.
Issues could arise when a on-path attackers (or, operational errors such as restoring a super old backup of a webserver) 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. Real world examples of old potential replayable certificates that today still would pass validation are here: 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, accepting such a cert will damage the RP's local validated cache. Parts of the validated output will disappear, in an unpredictably manner. Periodic reissuance of TA certs 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. How to repair this situation? 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: - February 2nd 2026 for phase 1, because 02-02-2026 is an unambiguous date both in the US and elsewhere. - March 3rd 2027 for phase 2, because 03-03-2027 also is unambiguous and visually is very distinct from the phase 1 date. The hope is that with this schedule global coordination less will be less error-prone, and everyone should get adequate preparation time. Discussed with various RIRs with & OK tb@
As always, testing this code requires a fresh snapshot or -current checkout. Further testing and feedback on how the code behaves will be welcome.
(Comments are closed)