Re: [Sidrops] feedback on draft-michaelson-rpki-rta
Martin Hoffmann <martin@nlnetlabs.nl> Tue, 12 January 2021 15:50 UTC
Return-Path: <martin@nlnetlabs.nl>
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 68BD83A09E0
for <sidrops@ietfa.amsl.com>; Tue, 12 Jan 2021 07:50:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_PASS=-0.001,
URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 42a-eIubctsK for <sidrops@ietfa.amsl.com>;
Tue, 12 Jan 2021 07:50:19 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net
[IPv6:2a01:4f8:fff0:2d:8::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 8C48D3A09D7
for <sidrops@ietf.org>; Tue, 12 Jan 2021 07:50:19 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.28])
(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 760D5600E3;
Tue, 12 Jan 2021 15:50:17 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by
soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl;
s=soverin; t=1610466617;
bh=uXgK339W4lJDZ8CJxejCYw9+hsLvK95xfC9502OHELE=;
h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
b=PWMen31uedWk5281D85F8kaXKvdGye82QNeuO9sirbZcIUDejVkkQkIphISIexIwH
ge9NjaH5p1dkHGBCT9rMaTQ1xYRgZqBxX5SF/EknYzz0yjDPH7Emi4LPM5LJqqJb56
FG9oJP4sd9UVXxOeCBc0EJZHnHx+8jkH2MKg1Z+nqBCDHIOMD78jeeNLrnNwj16uXT
fgUIOIVorphrTTKudXJDG5xWRiuOYYxmYXxqWo59wrZ5Q3HwCvQO/hL9FxrUtTrx/6
3/vSzhdrapc+6YqiRd2hJiXpWQqA+Gh5cp6k0KJgVr1lBSBrgoFm0TXMxvEZUmV/Lv
EGVCgNPJov0/w==
Date: Tue, 12 Jan 2021 16:50:15 +0100
From: Martin Hoffmann <martin@nlnetlabs.nl>
To: Ben Maddison <benm=40workonline.africa@dmarc.ietf.org>
Cc: SIDR Operations WG <sidrops@ietf.org>
Message-ID: <20210112165015.52a524bf@glaurung.nlnetlabs.nl>
In-Reply-To: <20210112145800.nocjbd4millmbx4i@benm-laptop>
References: <X+d3+e5Rj/Q7Dchv@bench.sobornost.net>
<20201229101412.GA56136@diehard.n-r-g.com>
<X+scpsd6kDQ72nLa@bench.sobornost.net>
<49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net>
<20201229151639.GD56136@diehard.n-r-g.com>
<X+tR06kF3aPZ4+18@bench.sobornost.net>
<20201230144836.ytg4u2gobkv4uzqn@benm-laptop>
<3BA339C3-EADC-449E-B5B2-7A4880E16EDA@nlnetlabs.nl>
<20210112145800.nocjbd4millmbx4i@benm-laptop>
Organization: NLnet Labs
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/oTiZuise2tmEaOetsFu80C4qra0>
Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta
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 15:50:22 -0000
Ben Maddison wrote: > > This was kinda the point I was making when I said that I couldn't > think of any use-cases for which multiple RTAs wouldn't work: > > The above logic works just the same if you instead have N RTAs over > the same signed data, and require that the union of `resources` from > each be the same as the set described in the signed data. > > Doing it this way seems to present the advantage of decoupling the > rpki-validation of the CMS blob from the > application-specific-validation of the underlying data. A drawback of this is, however, that you cannot decide anymore whether your document is truly "RTA invalid" or if you are just missing some of the data. Or, turned around, somehow loosing an RTA from the set makes the underlying data seem invalid even though it isn’t. This is quite similar to the situation we have in origin validation where loosing a ROA from the set may make a route invalid. Forcing all relevant data into a single object avoids this problem and makes an invalid a definitive invalid. > Every use case for this will require tooling to perform additional > validation of the signed data against the RTA (at least verifying the > digest, probably more), so this doesn't introduce a new step in the > process, it just moves responsibility for it out of the RTA spec. I’m not sure that is a desirable outcome. In its currently proposed form, RTA processing in its generic, application independent form handles all of the processing related to resources. You give it an RTA and a hash and it returns either a set of valid resources or a validation error. All of the application specific processing can be easily built around that. If RTAs are split, the application has to call into this interface multiple times and then has to decide how to merge the multiple results. That means each application has to define how to do that and both ends have to correctly do that. The work of dealing with resources under multiple parents has to be done. I think doing it once in a well-defined way is a better approach. - Martin
- [Sidrops] feedback on draft-michaelson-rpki-rta Job Snijders
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Claudio Jeker
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Job Snijders
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Stephen Kent
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Claudio Jeker
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Job Snijders
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Stephen Kent
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Ben Maddison
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Tim Bruijnzeels
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Korsback, Fredrik
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Tim Bruijnzeels
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Stephen Kent
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… George Michaelson
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Ben Maddison
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Martin Hoffmann
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Job Snijders
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… George Michaelson
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Job Snijders
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Job Snijders
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Martin Hoffmann
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Di Ma