An expired or missing CRL doesn't result in the manifest being considered invalid

This issue was also informally reported to RIPE NCC staff in late February 2020.

It appears that RIPE NCC validator doesn't consider an expired CRL cause to consider the associated manifest and underlaying objects invalid. It logs a warning, but does not consider this situation erroneous.

Theoretically a replay attack can be executed by making the CRL unavailable in a monkey-in-the-middle scenario, or presenting the validator with old data. The RPKI data download procedure in RIPE NCC's Validator must assume it is collecting untrusted data, which must be verified using the certificate verification model where an expired CRL means that none of the X509 objects pointing to the CRL can be validated or considered valid.

Some more (hard to read) context is available in the RPKI standards forum at IETF via https://mailarchive.ietf.org/arch/msg/sidrops/BKbYujWcr4qWJOahFoBqgZHrFX8/ and specifically https://mailarchive.ietf.org/arch/msg/sidrops/6bHseJeNPSsK0lebbNTDGFKVYsA/

If the CRL is expired, the manifest & directory should not be considered eligible for further processing and the associated VRPs should not be emitted to the RTR process. Manifests and CRLs compliment each other, manifests are not a replacement for CRLs.

The manifest specification assumes a sensible policy regarding CRL expiration is applied. Since RPKI does not have any other certificate revocation mechanisms other than CRLs (there is no OSCP and other tricks in the specs) - I believe that ignoring the CRLs expiration date opens up RIPE NCC's validator for replay attacks which can have adverse operational consequences (aka an attacker has the ability to flip BGP routes from valid to invalid)

To be transparent: I'm filing this bug publicly so I can reference this later on in a write-up about how these validation issues were handled.

RIPE-NCC / rpki-validator-3

An expired or missing CRL doesn't result in the manifest being considered invalid #162