Re: [Sidrops] 6486bis: Failed Fetches

Randy Bush <> Thu, 27 August 2020 15:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E1E093A0F02; Thu, 27 Aug 2020 08:40:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bVTzI3C71eRo; Thu, 27 Aug 2020 08:40:53 -0700 (PDT)
Received: from ( [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 334BE3A0ECA; Thu, 27 Aug 2020 08:40:53 -0700 (PDT)
Received: from localhost ([] by with esmtp (Exim 4.90_1) (envelope-from <>) id 1kBK1C-0006jQ-FX; Thu, 27 Aug 2020 15:40:50 +0000
Date: Thu, 27 Aug 2020 08:40:50 -0700
Message-ID: <>
From: Randy Bush <>
To: Stephen Kent <>
In-Reply-To: <> <>
References: <> <> <> <> <> <> <>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <>
Subject: Re: [Sidrops] 6486bis: Failed Fetches
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: Thu, 27 Aug 2020 15:40:55 -0000

> I agree with the observations made by Mikael and Job, i.e., that
> requiring strict conformance with manifest rules is the preferred
> approach.

otherwise, why the heck would we make them.  this non-compliance is
destructive.  i try to save civil disobedience for BLM etc.

> I suspect we disagree on what constitutes "correct." A correctly
> functioning CA does not publish objects with bad signatures or format
> errors, use certs that have expired, does not fail to replace expired
> or stale objects, does not include objects at pub points that are not
> on the manifest, etc.

this would seem to be pretty obvious, CA 101.

> No, it does not. What I suggested is that when a new object is
> proposed, it is the responsibility of the those proposing the new
> object to explain how it will be incrementally deployed.

cf router keys, ASPA

Job Snijders wrote:
> It pains me to write this email. It appears there is an increasingly
> acrimonious situation in which RIPE NCC, Cloudflare, and NLNetLabs
> representatives not only produce and publish insecure software, but
> also argue towards erosion of the robustness of the object security
> RPKI depends on.

you are too polite.  it is destructive of the internet and therefore
quite dangerous.

> I quote from the INTRODUCTION of RFC6486:
>     "A manifest is intended to allow an RP to detect unauthorized object
>     removal or the substitution of stale versions of objects at a
>     publication point."

seemed pretty simple at the time

so we have 6486-bis in progress.  but if some vendors have the arrogance
to continue these same games, why should we bother?

> Did any CA ever wish for an incomplete view of their routing
> intentions to be transformed into routing decisions? Zero CAs want
> this.

sad to say, given the "we can do whatever the hell we want" dogma, i
have my suspicions otherwise.  or is it just lack of ops clue?

> *** start of modified email ***
>     On Wed, Aug 26, 2020 at 08:24:42PM +0200, Martin Hoffmann wrote:
>     > Routinator and the RIPE NCC RPKI Validator have issues.
> *** end of modified email ***
> Do you see the issue now? I didn't even change the order of your words,
> I merely withheld some of the text you wrote, and the resulting text is
> entirely contradictory to what you intended to write!

yes.  but it is correct!  :)

> Believe it not, RIPE NCC, Cloudflare, and NLNetLabs are now at an
> existential crisis: your credibility is on the line.

no, for some of us, it's gone.