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