Re: [Sidrops] 6486bis: Failed Fetches

Randy Bush <randy@psg.com> Thu, 27 August 2020 15:40 UTC

Return-Path: <randy@psg.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E093A0F02; Thu, 27 Aug 2020 08:40:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVTzI3C71eRo; Thu, 27 Aug 2020 08:40:53 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 334BE3A0ECA; Thu, 27 Aug 2020 08:40:53 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from <randy@psg.com>) id 1kBK1C-0006jQ-FX; Thu, 27 Aug 2020 15:40:50 +0000
Date: Thu, 27 Aug 2020 08:40:50 -0700
Message-ID: <m23648xfjx.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
Cc: sidrops@ietf.org
In-Reply-To: <cf7030be-adc4-dde4-7eda-516339fd6c91@verizon.net> <20200827142827.GC88356@bench.sobornost.net>
References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <c1a8fffb-9106-d08e-4254-44ddf1a0115a@verizon.net> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <b71c9c88-fb10-b037-d06a-910711e51e04@verizon.net> <cf7030be-adc4-dde4-7eda-516339fd6c91@verizon.net>
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: <https://mailarchive.ietf.org/arch/msg/sidrops/NNvemv6avBd215baRHU4w1AS284>
Subject: Re: [Sidrops] 6486bis: Failed Fetches
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=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.

randy