From nobody Tue Sep 29 07:55:04 2020 Return-Path: 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 096963A0E98 for ; Tue, 29 Sep 2020 07:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 MfGf5inEZuPU for ; Tue, 29 Sep 2020 07:55:00 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 AF8EB3A0E96 for ; Tue, 29 Sep 2020 07:55:00 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:99f5:dd02:32ca:b184] (unknown [IPv6:2001:981:4b52:1:99f5:dd02:32ca:b184]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id D5DEC1F448; Tue, 29 Sep 2020 16:54:58 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1601391298; bh=xtdC6Q/NY/1J7w+qFuKkdQredmfg5+Ujz8dhNpkl3jM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=aDr08IfbiAs9G2epaK2dQdQpkvZcGwUbFtDjAH02NW1JcogAqCU+oq+pyPH6douDk mfUqFx4uBhQuX+4mwH0RTyt18yTOJvwP+fS8BQxvTTIsNJXcrZ1c/rvWdzR9tYc9IF BvkRJYYCK4tqJGtikUqHwyK6Ba3ZlMmiszZthVEo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Tim Bruijnzeels In-Reply-To: <52BFE652-380C-4403-936A-498C7756F013@nlnetlabs.nl> Date: Tue, 29 Sep 2020 16:54:58 +0200 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7F8B0EC3-C918-4455-A419-3E640471E63E@nlnetlabs.nl> References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <10b9622d-90b0-63e8-288e-858f88835284@verizon.net> <291655EE-2255-441B-B425-59BEE6DBE39F@nlnetlabs.nl> <0c7ab898-4031-3613-1382-228ef598c478@verizon.net> <52BFE652-380C-4403-936A-498C7756F013@nlnetlabs.nl> To: Stephen Kent X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 14:55:02 -0000 Hi, On 7 Sep 2020, at 13:17, Tim Bruijnzeels wrote: >=20 >>>=20 >>> If we do go down this road then I think that we should also look at = the manifest object itself, and let it convey which object (types) are = critical (and while we are at it, we can specify types instead of using = filename extensions). That way future object types could introduced more = easily perhaps - this obviously needs more discussion but it could even = allow for semantics like: 1) new object please test, don't use, 2) new = objects, use if you can, 3) new objects, critical - fail if you don't = understand. >>=20 >> One could combine the new SIA URI and a revised manifest, in which = the manifest contains the per-object flag, rather than redefining the = basic object format to accommodate the flag. That would reduce the = number of RFCs that need to change. Good idea. >=20 > Upon reflection I realised that even the introduction of an SIA in the = issuing CA certificate will lead to issues. RPs would reject the CA = certificate, and as a result the whole PP of the parent CA. This means = that the SIA cannot be deployed without leaving a significant number of = RP installations behind. E.g. if I run a delegated CA under an RIR which = wants to adopt ASPA, and I get a new CA certificate with the additional = SIA from my parent, then 1000s (RIPE NCC >12k) other CAs will also be = rejected. I have done some testing on this. Section 4.8.8.1 of RFC 6487 seems to say that additional SIA OIDs for CA = certificates can be expected and can be ignored. And indeed it seems = that all current RP software will accept (and ignore) additional SIAs. At least that's the result from adding an extra SIA in a Krill branch = and running the end to end tests using the following validator versions: fortvalidator 1.4.0 OctoRPKI v1.1.4 (2019-08-06T16:51:07-0700) rcynic version believed to be buildbot-1.0.1544679302 routinator 0.7.1 rpkiclient 6.7p1 rpkivalidator3 3.1-2020.08.06.14.39 I am still not very happy about the overhead that this approach implies: Additional publication points which need to be maintained, which may be = out of sync. What if MFT A has a certain ROA and MFT B doesn't? This can = lead to serious operational impact if an announcement would be valid = under one, but not the other. It would also require much more fundamental code changes for producing = CAs - one cannot just support a new object type. One has to support an = additional publication model. Parent CAs have to be willing to include = the new SIAs as well affecting the ability to deploy for delegated CAs. But, at least it seems that it can be introduced without breaking things = immediately for existing deployed validators. Tim=