Re: [Sidrops] Benjamin Kaduk's Discuss on draft-ietf-sidrops-6486bis-09: (with DISCUSS and COMMENT)

[Job Snijders <[e-mail]>]

Hi Rob, everyone,

Quick note from my side: this has not fallen off my radar. Based on
Rob's feedback I'm now trying to research the origins of the DISCUSS at
hand for a better understanding, and assessing what currently deployed
RP / CA implementations do. At times this work feels like attempting to
thread an arrow through two rings [1] :-)

Next week I hope to be able to circle back to the group with more
information, or a proposal for a path forward.

Kind regards,

Job

[1]: The Legend of Zelda: Breath of the Wild

On Sat, Feb 26, 2022 at 07:25:36PM -0500, Rob Austein wrote:
> Apologies for jumping in late here, I've been distracted by $dayjob
> (which has not been RPKI for many years now) and only just saw this.
> 
> I fear that I must object, strongly, to Job's proposed change:
> 
> > > ----- section 4: Manifest Definition ----
> > > 
> > > OLD section 4.2.1 second paragraph:
> > >    Because a "one-time-use" EE certificate is employed to verify a
> > >    manifest, it is RECOMMENDED that the EE certificate have a validity
> > >    period that coincides with the interval from thisUpdate to nextUpdate
> > >    in the manifest, to prevent needless growth of the CA's CRL.
> > > 
> > > NEW Section 4.2.1:
> > >    Because a "one-time-use" EE certificate is employed to verify a
> > >    manifest, the EE certificate MUST be issued with a validity period
> > >    that coincides with the interval from thisUpdate to nextUpdate in the
> > >    manifest, to prevent needless growth of the CA's CRL.
> > > 
> > > ----- Section 5: Manifest Generation ----
> > > 
> > > OLD Section 5.1 last paragraph:
> > >        It is RECOMMENDED that the validity interval of the EE
> > >        certificate exactly match the thisUpdate and nextUpdate times of
> > >        the manifest.
> > >        Note: An RP MUST verify all mandated syntactic constraints, i.e.,
> > >        constraints imposed on a CA via a "MUST".
> > > 
> > > NEW section 5.1:
> > >        The validity interval of the EE certificate MUST exactly match
> > >        the thisUpdate and nextUpdate times specified in the manifest's
> > >        eContent. (An RP MUST NOT consider misalignment of the validity
> > >        interval misalignment in and of itself to be an error.)
> 
> This business of pinning the manifiest EE certificate's validity
> period to the manifest's thisUpdate/nextUpdate interval has always
> been a bad idea, I've objected to it in the WG before, and we have a
> long sad history of operational disasters resulting from
> implementations that followed that recommendation.
> 
> The typical failure mode (demonstrated at least once each by three of
> the RIRs) is to pick a thisUpdate/nextUpdate cycle on the order of a
> day or so (reasonable), then go home for a long weekend, during which
> something breaks and no new updates occur.
> 
> The manifest thisUpdate/nextUpdate semantics are (deliberately) very
> much like the CRL semantics: failure to issue a new manifest by the
> nextUpdate time does not automatically invalidate all the existing
> data, it's just a hint that something might be wrong.  Think of it as
> a staleness indication.  Slightly stale, log a warning but no big
> deal (yet).  Gets stale enough, maybe you don't want to eat that.
> 
> Certificate expiration, on the other hand, is a hard failure.  When a
> manifest's EE certificate expires without being replaced, the data
> listed in the manifest is just gone.
> 
> So when an RIR does this with the manifest directly under their root
> certificate, a large portion of the total database goes away.  Oops.
> 
> Manifests only have EE certificates because they're a patch on the
> side of X.509.  If X.509 had allowed us to sign manifests using the CA
> certificate, as with CRLs, we would have done that.  But it doesn't,
> so we have the manifest EE certificates, OK, but that's no reason to
> kill large portions of the database every time an operator near the
> root of the tree says "oops".
> 
> All of this has been discussed before, and should be both in WG
> archives and in notes from face to face meetings (probably both the
> SIDR and SIDROPS WGs, not a new topic).
> 
> My own RPKI CA implementation uses the validity interval of the parent
> CA certificate as the validity interval of the manifest EE
> certificate, and has for about fifteen years now.  I'm not aware of
> any operational problems that have arisen as a result.
> 
> Yes, there's a potential issue of a CRL getting too long, but if it
> happens at all, it happens at a predictable rate, and one can always
> rekey if it's really becoming big enough to be a problem.
> 
> Job's proposed change makes the bad idea a requirement rather than
> just bad advice, hence my objection.