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

Nathalie Trenaman <> Mon, 23 March 2020 10:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB5EA3A0746 for <>; Mon, 23 Mar 2020 03:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Oe2W7zVnza3p for <>; Mon, 23 Mar 2020 03:34:46 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 75AAE3A0404 for <>; Mon, 23 Mar 2020 03:34:46 -0700 (PDT)
Received: from ([]) by with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <>) id 1jGKPs-0006WZ-Ni for; Mon, 23 Mar 2020 11:34:44 +0100
Received: from ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::f50]) by with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <>) id 1jGKPs-0000Uj-Jg for; Mon, 23 Mar 2020 11:34:44 +0100
From: Nathalie Trenaman <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
Date: Mon, 23 Mar 2020 11:34:43 +0100
References: <> <> <> <> <> <> <> <> <>
To: SIDR Operations WG <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3608.
X-ACL-Warn: Delaying message
X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a1cd9bfd5a623028df74a6498570934e6
Archived-At: <>
Subject: Re: [Sidrops] what to do when the CRL is hosed?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Mar 2020 10:34:49 -0000


> Op 27 feb. 2020, om 10:50 heeft Tim Bruijnzeels <> het volgende geschreven:
> Hi,
>> On 27 Feb 2020, at 09:59, Robert Kisteleki <> 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?