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

Job Snijders <> Tue, 24 March 2020 15:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD3543A0B07 for <>; Tue, 24 Mar 2020 08:11:07 -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 DrSUXhvXPX4Y for <>; Tue, 24 Mar 2020 08:11:06 -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 36DC33A0C16 for <>; Tue, 24 Mar 2020 08:11:06 -0700 (PDT)
Received: by with SMTP id g62so3907297wme.1 for <>; Tue, 24 Mar 2020 08:11:06 -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=7hFy4NRASjK2KGeo+tpWuTDXDqOAlN6L6RWtsXtMP3k=; b=AhlpsmMdTcXFGAh948WJy01WDxtYhz53tTaH/9BjzoM4Q4c2CWgtk7UVNf8e0voPll WZfRT1aVDTnVKSONEuY/Rfc1S4OSOUNe9RRbdGJOj7xW+DPsSGxRkgvrjv6NK+hFDo9d GDHu3hfya8NPLXZNBOq7KZvpqv3yb2e3X8gDNHcPEdPjIwGCo/gdb2NxN1UV82gh5Bpc 0N9RqpsQQG7/Vp0qxX20CamKqkdIRh/I3uT9y2NN+RrLgbmbcqMJVS860TxuR2VRmBRC V/6T8TmeTLwTFXgIADZQ2vVYJaD2sS1R+cAWS/YNQkySqRAzUs5Z59DhpA9VcdapU15Z u4Sg==
X-Gm-Message-State: ANhLgQ3gTHHoxqrFQ8wUl+g1rTUqDLaXOv9TMlRO7bOGBUxXEnvgyCKD G2xQwy7KlwxOJiIUNuZnIKaa8A==
X-Google-Smtp-Source: ADFU+vsXWwpeZBmd4uIksAECPJe5txISC33I6LWujcn6UEkE0cBca8FEmdw3gBncryt1BziO8zArnw==
X-Received: by 2002:a1c:9d0b:: with SMTP id g11mr6250261wme.77.1585062664407; Tue, 24 Mar 2020 08:11:04 -0700 (PDT)
Received: from ( []) by with ESMTPSA id l83sm4682858wmf.43.2020. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Mar 2020 08:11:03 -0700 (PDT)
Received: from localhost ( [local]) by (OpenSMTPD) with ESMTPA id cc8988db; Tue, 24 Mar 2020 15:11:02 +0000 (UTC)
Date: Tue, 24 Mar 2020 15:11:01 +0000
From: Job Snijders <>
To: Martin Hoffmann <>
Cc: Tim Bruijnzeels <>, 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 15:11:26 -0000

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,