IETF Logo Mail Archive

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

Tim Bruijnzeels <tim@nlnetlabs.nl> Thu, 27 February 2020 09:50 UTC

Return-Path: <tim@nlnetlabs.nl>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073883A16BB for <sidrops@ietfa.amsl.com>; Thu, 27 Feb 2020 01:50:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_kScBSMMpxt for <sidrops@ietfa.amsl.com>; Thu, 27 Feb 2020 01:50:21 -0800 (PST)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 716313A16C3 for <sidrops@ietf.org>; Thu, 27 Feb 2020 01:50:21 -0800 (PST)
Received: from [IPv6:2001:981:4b52:1:dc65:bf07:8257:debe] (unknown [IPv6:2001:981:4b52:1:dc65:bf07:8257:debe]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 9DCE12DE3F; Thu, 27 Feb 2020 10:50:19 +0100 (CET)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1582797019; bh=NNSIgSba+MCgsUoQ2EFaYvXGaNitpdJU0YI6pCdjJ+U=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=o+U6UZ00wP9NG2uL5gQN29E+vPZuX9RrzbArx1RGgvS18OsPMOioTVs3TpKFNb6uH q23GaVcn/NiDBiyRgg9rTOzEI7B3/jG3Ra4i6wPaj6r6HR4lS/8A+B9HCiVoKjSegS h8cZ443dX/tx2QMb2yKrPWeJSJqepX4hJO3kFJg0=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net>
Date: Thu, 27 Feb 2020 10:50:19 +0100
Cc: Job Snijders <job@ntt.net>, sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8B09B96B-432C-4190-9DE0-DC2004AAFCC2@nlnetlabs.nl>
References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net> <20200226173935.GE72144@vurt.meerval.net> <2db8d19a-6f91-d2fc-36c3-65742ba77e6c@ripe.net>
To: Robert Kisteleki <robert@ripe.net>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/UYDhHJjiyIPNsD8PZOY5P1Iva0w>
Subject: Re: [Sidrops] what to do when the CRL is hosed?
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2020 09:50:23 -0000

Hi,

> On 27 Feb 2020, at 09:59, Robert Kisteleki <robert@ripe.net> 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.




Regards
Tim

> 
> Regards,
> Robert
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops

v2.23.0 | Report a Bug | By Email