Re: [Sidrops] feedback on draft-michaelson-rpki-rta

Martin Hoffmann <martin@nlnetlabs.nl> Tue, 02 February 2021 16:56 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 0AF663A0C03 for <sidrops@ietfa.amsl.com>; Tue, 2 Feb 2021 08:56:22 -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=unavailable 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 ncW7detofuBs for <sidrops@ietfa.amsl.com>; Tue, 2 Feb 2021 08:56:16 -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 7989B3A0C06 for <sidrops@ietf.org>; Tue, 2 Feb 2021 08:56:16 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.24]) (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 566E7601B3; Tue, 2 Feb 2021 16:56:14 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1612284973; bh=01/Glh2CSkUEuxR45rni9f08jr7IISfnfwP61LcUKJc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=f0WWrbniwk5Ybk2l/1WdTLe3djxiNnL4OKa0Zp3ksK/4ZWKV0ID0O0u9M4uHY9mhb H8ZzGNNO7sQ7uNNWgXXtxMBhV2XO7v45LB3/wyiublQHL+j8gAt8agD1VKuey30LUQ 1rIb4iMpzKZxirtbFhLKO2Qw81vCPap6ocno2E6DuX4hc6Sqe2rnpPfpgCEZJITVOX d2WzxWmDCbe44qDFmpAYcjRt0AqDIFfZcjy4+Zvz61VBcG6SHS3m8DBHdKhU628uw1 wmTWqR5WRzawFRE+30K+ryjeTSMF/xI4mxzPqA6hwGX6C5PeljjEVNP15DF6mRM5Vz cWXzu0hqoGebg==
Date: Tue, 2 Feb 2021 17:56:08 +0100
From: Martin Hoffmann <martin@nlnetlabs.nl>
To: Job Snijders <job=40fastly.com@dmarc.ietf.org>
Cc: sidrops@ietf.org
Message-ID: <20210202175608.0e8a58cb@glaurung.nlnetlabs.nl>
In-Reply-To: <YBl2TH9FiBf6iKFt@snel>
References: <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> <X/31sdsc/ZzGDsjf@bench.sobornost.net> <CAKr6gn3z_N=xGbScwe3xTUxbqWwySwAkncSbm0KKyDZjwVucOA@mail.gmail.com> <YBl2TH9FiBf6iKFt@snel>
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/gr96i5V5r-FjE1FQLx8NAmoiJBU>
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, 02 Feb 2021 16:56:22 -0000

Job Snijders wrote:
> 
> I've consulted with various subject matter experts, and at George's
> request I again reconsidered. Unfortunately I could not arrive at a
> different conclusion about the current RTA proposal, it is too
> complicated for me to support.

There’s a detail I would like to point out: You can only use the
existing software more or less unchanged if you distribute RTAs through
the regular RPKI repository system. I think doing so is a bad idea
for two reasons.

For one, an RTA is an exchange between a very small number of
participants -- typically just two --, but distribution via the RPKI
repository system results in every single relying party having to
downloading the object. That strikes me as rather wasteful. At the very
least relying parties need to download the object and calculate a hash
over them to determine whether the manifest is valid. Every one needs
to do that. Yet only really one or two parties actually care.

Second, distribution through the RPKI repository is actually quite
cumbersome as it involves a kind of break of gauge: You exchange
documents in whatever way you choose (likely some kind of HTTP API) but
then have to stop, fire up an RPKI relying party tool and wait until it
sees the promised object. Because there uncertainties in timing of RPKI
publication, you need to be prepared to wait for quite a bit.

If, conversely, the RTA can be distributed by any other means, i.e., it
is just a file, it can be transferred as part of your document
exchange. Bundle it with your document for automated processing or
upload it manually via a browser. No waiting involved: both parties
know that the RTA has been transmitted.

But if you allow that, you can’t use RFC 6488 signed objects anymore --
or, well, not properly since at the very least you don’t have the a
signedObject SIA rsync URI anymore. (And yes, the current draft glances
over this fact.)

So, if you have to change your code anyway, why not allow it to deal
with a legitimate, existing use case?

In addition to allow multiple signatures, the draft also allows the
signer to include all necessary certificates and CRLs so that for
validation you wouldn’t even need to access the RPKI repository system
at all. Needless to say, doing that requires quite a bit of different
code but, I do believe that this is worth it, as it seriously
streamlines any process that involves validating RTAs as it can now be
done in a library pretty much without keeping state.  

  - Martin