IETF Logo Mail Archive

[Sidrops] RFC 8360 / 6487 (Was: RPKI Outage Post-Mortem)

Job Snijders <job@sobornost.net> Tue, 12 January 2021 18:56 UTC

Return-Path: <job@sobornost.net>
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 B1A0E3A0DE2 for <sidrops@ietfa.amsl.com>; Tue, 12 Jan 2021 10:56:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 S4YdHdMdA2kc for <sidrops@ietfa.amsl.com>; Tue, 12 Jan 2021 10:56:50 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 586083A0FC2 for <sidrops@ietf.org>; Tue, 12 Jan 2021 10:56:50 -0800 (PST)
Received: from smtp.freedom.nl (unknown [10.10.3.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 7BC44600E9 for <sidrops@ietf.org>; Tue, 12 Jan 2021 18:56:48 +0000 (UTC)
Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net
Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id c16753a8; Tue, 12 Jan 2021 19:27:28 +0000 (UTC)
Date: Tue, 12 Jan 2021 19:27:27 +0000
From: Job Snijders <job@sobornost.net>
To: sidrops@ietf.org
Message-ID: <X/34H009eeuRcUf1@bench.sobornost.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/qaLp9-z9dhqRJhkOLhEFiCiMfOM>
Subject: [Sidrops] RFC 8360 / 6487 (Was: RPKI Outage Post-Mortem)
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: Tue, 12 Jan 2021 18:56:53 -0000

Dear group (specifically George, Geoff, Tim, Carlos, Andrew & Daniel),

I'd like to ask SIDROPS to read this message
https://www.ripe.net/ripe/mail/archives/routing-wg/2021-January/004220.html
(please ignore point 1 & 2 as those are now resolved) 

What is the current plan to get RFC 8360 deployed at scale? Is this on
anyone's radar?

The spec has in the making for ~ 8 years and seems to contain a lot of
valuable insight. To me RFC 8360 seems to be to RPKI what RFC 7606 is to
BGP. A revision to increase operational robustness, except... 7606
actually got deployed :-)

Which of the Trust Anchor will be first to flip the switch?

Or... do CA implementers & operators consider jumping to the new RFC
8360 codepoint too risky of a move... and should an alternative strategy
be devised?

Was it (in hindsight) a mistake to not deprecate RFC 6487, but instead
specify a new optional alternative policy?

Kind regards,

Job

v2.23.0 | Report a Bug | By Email