Re: [Sidrops] what to do when the CRL is hosed?

[Claudio Jeker <[e-mail]>]

On Mon, Mar 23, 2020 at 11:34:43AM +0100, Nathalie Trenaman wrote:
> Hi,
> 
> > Op 27 feb. 2020, om 10:50 heeft Tim Bruijnzeels <[e-mail]> het volgende geschreven:
> > 
> > Hi,
> > 
> >> On 27 Feb 2020, at 09:59, Robert Kisteleki <[e-mail]> wrote:
> >> 
> >> 
> >> 
> >> On 2020-02-26 18:39, Job Snijders wrote:
> >>> I think the entire repository should be considered invalid if a single
> >>> file is missing but was referenced in the manifest. One can't produce
> >>> rules based upon false or incomplete data, and one can't protect against
> >>> hijacks using unsigned data.
> >> 
> >> I'm not sure that'd be wise. Knowing you're missing something does not
> >> invalidate the other bits that you can verify. Exactly what you keep
> >> using can depend on what's missing (a CRL, a CA cert, a ROA, ...) though.
> > 
> > I am not saying that I have the complete answer here, but I think it's worthwhile to discuss this further - if the WG is willing to consider updates to the manifest RFC.
> > 
> > It gets complicated.
> > 
> > ROAs at the parent level have the ability to invalidate announcements by children that run delegated CAs. If their CA cert is missing, then this can impact ROV to the point that announcements by children are considered invalid.
> > 
> > In such cases it might be better to mark objects the ROA objects as invalid so that ROV yields not found. It is probably okay to recurse any other CA cert and use ROAs found under it. Probably, because probably they are more specific, and ROAs there would not invalidate covering, presumably, less specific announcements done by the parent (yes, lots of assumptions here). For BGPSec certificates things get more complicated, because at the MFT level they are indistinguishable from delegate CA certificates. Also BGPSec does not have a soft-landing, so invalidating certificates (rather than ROAs) might be quite harmful.
> > 
> > Note, I think this should be applied only to *missing* objects as that indicates either a failure to publish things properly, or possibly a partial withhold attack where the RP receives incomplete information. And even then, there may be ways to recover if an RP still has prior copies of all missing objects (check hash).
> > 
> > If objects are found and accounted for, but they turn out to be invalid, then I believe that other objects should not be impacted.
> > 
> 
> I would still welcome discussion on this. For our Validator, we
> currently issue warnings if there is something wrong with the CRL. Some
> other RP (validator tools)  invalidate the chain, one ignores the CRL.
> This is not a good situation. 
> From the mailing list, I didn’t see a clear consensus (yet?) for RP
> (validator tools). Any ideas? Thoughts? Did I miss something?
> 

I think the current discussion did show that RP tools should do the proper
validations and not skip steps.

As for rpki-client we still believe that doing strict checks of the
certificates is the right thing. rpki-client will exclude certs and the
data they protect if they do not validate (this includes not-valid before
and after timestamps of both the certificate and the CRL (if any)).
Additionally all hash values in mft files are verified and again objects
failing validation are excluded. The result is that only fully valid VRP
are exported and all others are skipped but a warning is logged. 

-- 
:wq Claudio