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

Oleg Muravskiy <> Tue, 24 March 2020 15:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 07BBE3A08B6 for <>; Tue, 24 Mar 2020 08:36:23 -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 frfXsak5jC7u for <>; Tue, 24 Mar 2020 08:36:21 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30DAE3A08B5 for <>; Tue, 24 Mar 2020 08:36:21 -0700 (PDT)
Received: from ([]) by with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <>) id 1jGlbH-0006tx-LT; Tue, 24 Mar 2020 16:36:19 +0100
Received: from ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::2aa]) by with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <>) id 1jGlbH-0006aA-I2; Tue, 24 Mar 2020 16:36:19 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
From: Oleg Muravskiy <>
In-Reply-To: <>
Date: Tue, 24 Mar 2020 16:36:19 +0100
Cc: SIDR Operations WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: Job Snijders <>
X-Mailer: Apple Mail (2.3608.
X-ACL-Warn: Delaying message
X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b744451ee5fc64e9cd8f96750ed5f9ca6bd
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 15:36:24 -0000

> On 24 Mar 2020, at 16:11, Job Snijders <> wrote:
> On Tue, Mar 24, 2020 at 03:20:09PM +0100, Martin Hoffmann wrote:
>> Job Snijders wrote:
>>> I'm not sure I agree - routinator, fort and octorpki are trivially
>>> forced to use rsync if the attacker blocks TCP port 443.
>> At least Routinator does not fall back to rsync once it has
>> successfully completed accessing the repository via RRDP once. I am
>> open to strengthen this to not ever use rsync if there is a RRDP URI
>> in the certificate. 
> I'm interpreting the willingness to attempt to make MITM attack slightly
> harder as an indicator that the described MITM partial
> withholding/corruption attack scenarios are valid and problematic. :-)
> I don't think a conclusion about the integrity of the DELTA snapshot can
> be derived from the fetch mechanism itself: just because it was
> retrieved over HTTPS doesn't mean there was no MITM attack. The
> diginotar situation comes to mind, and crazier things have existed in
> the wild.
> The hashes used in the RRDP file format provide a degree of integrity
> checking useful for the filetransfer itself, but don't seem to be meant
> to verify any authenticity. This to me means that after downloading and
> unpacking the RRDP snapshot, we still have to assume the data may have
> been meddled with and some strategic files might have been either
> corrupted or are missing.
> The decision tree I see currently as 'safer' would be as following:
> 1) are all files referenced in a given manifest present?
> 2) do the hashes as listed inside the manifest match the contents of the referenced files?
> 3) is the CRL present and valid?
> 4) are all of the relevant signatures from not-revoked keys?
> If the answer to any of the above questions is 'no', I think the leaf of
> the tree at hand should be considered invalid to prevent tainting the
> RFC 6811 validation procedure with incomplete data.
> Kind regards,
> Job


Your examples so far have showed that continuing with incomplete set of ROAs after a withhold/manipulation on ROA objects might create dangerous situation.

Are there scenarios where withholding / making invalid a certificate, for example, leads to a similar danger?

I wonder if this is specific to ROA objects only, and whether we should treat them differently. If it is, then we could “ignore” all published ROAs at the specific publication point, but continue validation to child certificates and their sub-trees.