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

Job Snijders <> Tue, 24 March 2020 13:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F32D3A0BDE for <>; Tue, 24 Mar 2020 06:58:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.111
X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KJDc58nghCth for <>; Tue, 24 Mar 2020 06:58:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EEC2F3A0BF0 for <>; Tue, 24 Mar 2020 06:58:33 -0700 (PDT)
Received: by with SMTP id 65so4861716wrl.1 for <>; Tue, 24 Mar 2020 06:58:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=2foSOj8dqMAR246F2ElEnHLf4BtdvlzD5GnpFgFCO5M=; b=cfe7sodsUZW6/4JvZ6lM4gt4wGyvpxXjAtGgAxbCB54h09VGlR/7vAaF3QS2l0uRwW ANa6ANAft/ZrmaySDhSfOVNduGdbbQ23vrMQtTyZibKKpsCNtRZ2MmBoRBbiaeusQLWQ EmoP34/AoLX8yV/CyapE+Ewgt4YHrniRUkwFncStcqHa+nVvKO3fi10Po39k3/hbWRF/ K2INLJCxt8cELKbTHLYMKgM4si+fdAYyrTDNRlXJQ2ABmTc0k+W03jaz4JHPH9VavdKN 4etW6CxKjT3lo/PDfBwsXuB9c+AelzJahmnXS8oeKqSaLEN2Iif9SYzGcgi/+CLwq07C fywg==
X-Gm-Message-State: ANhLgQ3xnpviLfHZMOaD/7PDGvVz5/PfjZ2O7Vwcswte9uWI0NlN+kFq +7jv6kybZwas7X9UdKdX2KPuozSnkRc=
X-Google-Smtp-Source: ADFU+vvZS4n984eAQpGx5sDbDt8ErP8Cr3FxRToTWqdP2VmLggu/cYTvdv8hTfFL+VqZoTUVwVsCGw==
X-Received: by 2002:a5d:6a01:: with SMTP id m1mr27701107wru.353.1585058310973; Tue, 24 Mar 2020 06:58:30 -0700 (PDT)
Received: from ( []) by with ESMTPSA id f9sm29839203wro.47.2020. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Mar 2020 06:58:30 -0700 (PDT)
Received: from localhost ( [local]) by (OpenSMTPD) with ESMTPA id c06c980c; Tue, 24 Mar 2020 13:58:29 +0000 (UTC)
Date: Tue, 24 Mar 2020 13:58:28 +0000
From: Job Snijders <>
To: Tim Bruijnzeels <>
Cc: SIDR Operations WG <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
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: Tue, 24 Mar 2020 13:58:53 -0000

On Tue, Mar 24, 2020 at 10:42:37AM -0300, Tim Bruijnzeels wrote:
> >> As I wrote before, I believe that a single mistake (withheld /
> >> unpublished object or even a bit flip) invalidating a whole
> >> repository,
> > 
> > Some nuance could be added: it depends on where the error in the
> > tree exists. If a top level manifest or CRL is hosted, indeed
> > everything underneath it should be tossed. But for instance when a
> > manifest 'at 2 levels deep', references a file that doesn't exist,
> > you only need to toss that specific manifest (at least). So, yes,
> > errors in the repository should result in the repository (or parts
> > of it) being considered inadmissible.
> > 
> > RPKI started out on the premise that an unencrypted transport
> > (rsync) was acceptable, because everything was signed and
> > cryptographically verifiable. Now we are in a situation where the
> > transport channel *is* insecure, and the data transmitted across it
> > is not properly verified. Validators are *knowingly* proceeding to
> > produce VRPs with incomplete, expired, and/or corrupted data.
> With RRDP over HTTPS a lot of in transit / MITM issues are mitigated.

I'm not sure I agree - routinator, fort and octorpki are trivially
forced to use rsync if the attacker blocks TCP port 443.

> The RFC currently still says that invalid certificates should be
> accepted though. The thought at the time was that we have object
> security and people make too many mistakes configuring HTTPS. With
> Letsencrypt I believe this argument no longer holds.

Yeah, I recall the discussions ~ a year ago about that section of the
RFC. Unfortunately it turns out that we (as RP implementers) appear to
lack some checks in the RP software to be able to say we have 'object
security'. I also believe that the onus is on the CA operators to
correctly configure their HTTPS service. A misconfiguration of HTTP TLS
service of the RRDP publication point *should* result in the publication
point being dismissed (and perhaps use the local cache for what its

> First off I agree with Job that it would be better to disregard
> information that is known to be a partial version of the truth.

An additional check is needed: if one of the .roa files a manifest
references is corrupt (the MITM didn't delete strategically file, but
instead filled a .roa file with garbage), the anything referenced in
that manifest should be considered invalid.

an example, on my MITM box I did 'echo XX > fIeCcC8KpdJQd-olU2APdxNZkyA.roa',
so the .roa file exists, but the RP can see there is a mismatch between
the hash in the manifest and the hash derive from the
fIeCcC8KpdJQd-olU2APdxNZkyA.roa file. If a validator proceeds to output
VRPs based on the remaining (parseble) .roa files, you end up with an
incomplete set:

job@anton ~$ grepcidr /var/db/rpki-client/openbgpd source-as 3320 source-as 0 source-as 3320 source-as 3320 source-as 3320 source-as 3320 source-as 3320 source-as 3320 source-as 3320 maxlen 24 source-as 34086 maxlen 24 source-as 2792

In the above eaxmple there should be ~ 19 VRPs in total,
fIeCcC8KpdJQd-olU2APdxNZkyA.roa contained 8 VRPs.

I suppose we must consider a 'partial withholding attack' equivalent to
a 'partially corrupted attack'.

In summary:

If a manifests references a non-existing file, or if there is a mismatch
between the hash listed in the manifest and the hash as derived from the
.roa or .crl files, the RP MUST consider the whole manifest invalid and
MUST not produce VRPs with the remaining .roa files.

Kind regards,