Re: [Sidrops] 6486bis: referenced object validation

Job Snijders <> Fri, 04 December 2020 12:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B96593A0C01 for <>; Fri, 4 Dec 2020 04:13:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vv5B-5y8lTKB for <>; Fri, 4 Dec 2020 04:13:36 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA7C63A0BF8 for <>; Fri, 4 Dec 2020 04:13:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPSA id 6AA9722014A; Fri, 4 Dec 2020 12:13:34 +0000 (UTC)
Received: from localhost ( [local]) by (OpenSMTPD) with ESMTPA id a9c4da58; Fri, 4 Dec 2020 12:13:32 +0000 (UTC)
Date: Fri, 04 Dec 2020 12:13:32 +0000
From: Job Snijders <>
To: Tim Bruijnzeels <>
Cc: Martin Hoffmann <>, SIDR Operations WG <>, Ben Maddison <>
Message-ID: <>
References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <> <> <>
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] 6486bis: referenced object validation
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: Fri, 04 Dec 2020 12:13:41 -0000

On Fri, Dec 04, 2020 at 11:44:17AM +0100, Tim Bruijnzeels wrote:
> > On 4 Dec 2020, at 11:40, Job Snijders <> wrote:
> > On Fri, Dec 04, 2020 at 11:16:51AM +0100, Martin Hoffmann wrote:
> >> Under this approach, the manifest expresses which objects the CA
> >> intended to publish. If all the objects listed on the manifest are
> >> present with a matching hash, the publication point reflects the
> >> intent of the CA and can be processed. If it contains invalid objects,
> >> these can be discarded individually.
> > 
> > Indeed, I believe you've now captured the essence of why manifests
> > exists at all. This is what rpki-client & FORT seem to have implemented.
> I suggested this in August:
> I think a lot of this could have been avoided if we had this
> discussion then, but I welcome this now..

Looking back I'm at a loss how "a lot of this" really could've been
avoided. What additional steps or process should I have followed for
NLNetLabs/RIPE/Cloudflare to sooner understand the problem with their
implementation choices and encourage those organisations to provide a
solution to their users?

As you know, I reported 'this' as a problem in February 2020 to sidrops@

OpenBSD rpki-client implemented the 'this' solution already in March

FORT implemented also implemented the 'this' solution already back in
March 2020

To protect its business, NTT deployed 'this' in their transit-free
network in April 2020, further proving the viability of the approach on
global scale.

I reported 'this' again as a problem & mentioned the solution in April

We had *multiple* virtual SIDROPS meetings where I and others kept
repeating the issue and the solution, in simple english: ignore the
manifest when files are missing or corrupted. Additionally, ignore
objects that are expired or otherwise invalid.

Two RP implementers told me they *first* wanted to see a nearly finished
or even published RFC, before making any changes to their code. I think
RFC-first-code-later is an entirely unworkable model for cryptographic
software actively used in the field. It seems weird to me to set the bar
so high before addressing simple software defects. Conversely, IDR
requires 2 implementations *before* RFC publication (which helps avoid
lots of problems in RFC texts^W^W^W^W^W^W^Wimprove quality of RFCs), a
ritual which I think should be followed by SIDROPS as well.

RFC compliance (or a perception thereof) is very important for
system interopability, but not the end goal in and of itself.

The real goal is to keep the network running, where in this context our
role is to create software for network operators for them to securely
validate the wishes of the Internet number resource holders.

We have to keep the Internet running *while* we discuss things in IETF.
Drafts/RFCs are the byproduct, they come after the coding effort and
deploying the code.

Kind regards,