Re: [Sidrops] weak validation is unfit for production (Was: Reason for Outage report)

Lukas Tribus <lukas@ltri.eu> Fri, 28 August 2020 17:36 UTC

Return-Path: <lukas@ltri.eu>
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 57D633A0EDD for <sidrops@ietfa.amsl.com>; Fri, 28 Aug 2020 10:36:57 -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_PASS=-0.001, URIBL_BLOCKED=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 NgP9DsCV5cFo for <sidrops@ietfa.amsl.com>; Fri, 28 Aug 2020 10:36:55 -0700 (PDT)
Received: from mail5.web-server.biz (www5.web-server.biz [185.181.105.105]) (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 971A03A0EDB for <sidrops@ietf.org>; Fri, 28 Aug 2020 10:36:55 -0700 (PDT)
Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail5.web-server.biz (Postfix) with ESMTPSA id DABD447C79 for <sidrops@ietf.org>; Fri, 28 Aug 2020 17:36:48 +0000 (UTC)
Received: by mail-io1-f41.google.com with SMTP id g13so2189058ioo.9 for <sidrops@ietf.org>; Fri, 28 Aug 2020 10:36:48 -0700 (PDT)
X-Gm-Message-State: AOAM530vehVBTq8KfOgU72SgOZAR/UPIuGpfwSWWrlN40B0lPFnSU/CD H2jVabQkvJ20dELh/fjhAhltUKdqW2SUojxNSsU=
X-Google-Smtp-Source: ABdhPJw14UONBHxoE9lmkkue3Kap+xLj9qdOLFv5dziZNC/xoIBHSENI1aTxVCfPExyGovXxZTn5mXE8mFr0l5CmJaI=
X-Received: by 2002:a6b:fb0c:: with SMTP id h12mr1809887iog.98.1598636207279; Fri, 28 Aug 2020 10:36:47 -0700 (PDT)
MIME-Version: 1.0
References: <DE33EFAE-FBD2-478F-92A9-1FBD81CCC43F@arin.net> <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <20200827142827.GC88356@bench.sobornost.net> <DEBF83EC-B5B7-490B-9F30-19571991E273@nlnetlabs.nl> <045cb11f-5eea-1568-5260-d9794143dc7a@verizon.net>
In-Reply-To: <045cb11f-5eea-1568-5260-d9794143dc7a@verizon.net>
From: Lukas Tribus <lukas@ltri.eu>
Date: Fri, 28 Aug 2020 19:36:33 +0200
X-Gmail-Original-Message-ID: <CACC_My8f9W6njP51ByBK_gffQfUx4Tmmkhmdb7FomK3idp2HbA@mail.gmail.com>
Message-ID: <CACC_My8f9W6njP51ByBK_gffQfUx4Tmmkhmdb7FomK3idp2HbA@mail.gmail.com>
To: sidrops@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/RpTyqdj_Ns9J6h2IJywhci2RJiQ>
Subject: Re: [Sidrops] weak validation is unfit for production (Was: Reason for Outage report)
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: Fri, 28 Aug 2020 17:36:57 -0000

Hello,


On Fri, 28 Aug 2020 at 16:00, Stephen Kent
<stkent=40verizon.net@dmarc.ietf.org> wrote:
> I am very bothered by the observation that, if were were to strictly
> enforce the requirements imposed by the RPKI RFCs, then the number of
> verified routes would substantially decrease.

This I believe is at the core of the disagreement.

There is a faction that argues with points that sound a lot like "if
in doubt, consider the ROA valid, because we NEED to emit a VRP",
"CA's are too big to fail" and equivalents of "but if HTTPS fails,
people will just use HTTP so we end up being less secure" (as in
"better have a stale VRP than no VRP at all"). This is a mindset thing
and goes beyond the specific issue about manifest invalidation. For
example some RP's accept stale objects by default.

Err'ing on the side of caution seems to mean "consider the ROA valid,
so we emit the VRP" for some, which as a network operator I find
deeply troubling.

Let's be honest: there are not a lot of incentives for the CA's to fix
underlying issues if the 3 major RP's accept those ROA's.

Yes, sure, all of this is an oversimplification and the devil is in
the details, which do need clarification.


But we cannot be guided by a fear of decreasing VRP numbers when
improving validation. Immaggine if browsers would do that with WebPKI
(and that is actually causing direct outages for users, as opposed to
ROV where outages are more likely caused by the *presence* of VRPs
than by its absence).


-- lukas