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

Di Ma <> Fri, 05 February 2021 05:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE1913A0CC7 for <>; Thu, 4 Feb 2021 21:13:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id taPWku06djZe for <>; Thu, 4 Feb 2021 21:13:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 97F3B3A1BFD for <>; Thu, 4 Feb 2021 21:13:17 -0800 (PST)
X-QQ-mid: bizesmtp23t1612501988tpodhl2d
Received: from [] (unknown []) by (ESMTP) with id ; Fri, 05 Feb 2021 13:13:07 +0800 (CST)
X-QQ-SSF: 00400000002000Z0Z000000A0000000
X-QQ-FEAT: sj2Ih1w5Qj8dXP6xgYXqehF+553hYit8bQI6bPuFV84ktD/xQM8Ds1V6TXN8V 174kSpU/VAP25Ohw0Kx1ZqSdvvFQt4SS62XEOLn0rmEe4jWrFOpe0w0lMK/xUBnLzc8lHUs 8l35AI0jr0t8In1hz4veg7Dr/d8YLruKG8WHdmlAaorqfSvDQaOXhXRPEFOnEGnEbQ2pu4f GmGN+xaNC0cjlrTkgRte5aGN/XaTMWuntY4uSMnvRF3IppCEXn7+duk/wg8Alse71hLGeUl qxPy+Gc0eX0U/ArrCW0UoF+MI51ISQJB2z2jUploiqbs8+OnTbyUNd85q4H0XkojCTMnh92 Bl2HO3RG7/f1T5nM26e23857a8UxbyzsqqPyhsFXdK7SGOM9AU=
X-QQ-GoodBg: 2
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Di Ma <>
In-Reply-To: <>
Date: Fri, 5 Feb 2021 13:13:03 +0800
Cc: Job Snijders <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <20201230144836.ytg4u2gobkv4uzqn@benm-laptop> <> <20210112145800.nocjbd4millmbx4i@benm-laptop> <X/31sdsc/> <> <YBl2TH9FiBf6iKFt@snel> <>
To: Martin Hoffmann <>
X-Mailer: Apple Mail (2.3654.
X-QQ-Bgrelay: 1
Archived-At: <>
Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta
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: Fri, 05 Feb 2021 05:13:25 -0000

Based our experience of evolving and operating RPSITR2, I don’t really think multiple signatures on RTA is good idea as per current RPKI repository architecture. It will bring about complexity to RP’s validation algorithm.

Through a separate system that RPs achieve RTAs could be an option.


> 2021年2月3日 00:56,Martin Hoffmann <> 写道:
> 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
> _______________________________________________
> Sidrops mailing list