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

From: Job Snijders <[email-masked]>
Date: Tue, 2 Feb 2021 16:57:00 +0100

Dear group, authors,

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. It appears I'm not the only one
questioning the current RTA approach:

Tim offered a very insightful and honest write-up [1], I'll cherry-pick
from what he and others wrote:

     "It is true that requiring single signing for RTAs simplifies the
     specification."

Stephen Kent states [2]:

    "Your characterization of the added complexity and validation
    failure possibilities is worrisome"

Fredrik Krosback says [3]:

    "we do not know the full extent of which software is out in the wild
    that may or may not need full refactors to handle this."

Rob Austin on RFC 6488 (August 2010) [4]:

    "As an implementor I really want to use a common code path to
    validate the common portions of all objects of this general form,
    and would really prefer a single specification of what that code
    should do. :)"

Richard L. Barnes (August 2010) [5]:

    "This document (red: RFC 6488) seems like a good approach to
    maintaining some sort of long-term architectural sanity in the RPKI,
    maybe even something that could simplify tool-building."

For rpki-client (and I suspect FORT and OctoRPKI too) the above
statements hold true: I think single-signer RTA can be implemented in a
relatively short span of time (repurposing existing code such as the ROA
codepaths). On the other hand multiple-signer requires significant
refactoring. As for the suggestion to just not support RTAs produced by
multiple-signers: I'm not comfortable with latent capabilities, this is
security orientedd software after all. Today's latent capability is
tomorrow's landmine.

So... if the authors wish to deviate from RFC 6488, are they willing to
do the real legwork and write 6488bis to change the below part?

    "Additionally, the SignerInfos set MUST contain only a single
    SingerInfo object"

If the authors really wish to continue RTA with the innate ability for
multiple signers within a single RTA object, I'll step out of the way.
Endless bickering does not help us here.

However, I hope there will be understanding if I spin up a 'competing'
draft to address a similar solution space as RTA covers, this time in
full compliance with RFC 6488. OIDs are cheap and the market usually
favors simplicity.

Kind regards,

Job

[1]: https://mailarchive.ietf.org/arch/msg/sidrops/pSIibdv-x7NgV1D9tDBx1HvYTTo/
[2]: https://mailarchive.ietf.org/arch/msg/sidrops/gx5SQI8DzRFnU2DZrZdH6rdW8Tc/
[3]: https://mailarchive.ietf.org/arch/msg/sidrops/hNKSvMFXIQzbH5TsiDgFqy-lqpE/
[4]: https://mailarchive.ietf.org/arch/msg/sidr/Zo3Hg1AwqqUi4tD1fWmd2aqTANU/
[5]: https://mailarchive.ietf.org/arch/msg/sidr/esWy85UvfjvO7N95pfZHBYQGOVY/

---

From: Martin Hoffmann <[email-masked]>
Date: Tue, 2 Feb 2021 17:56:08 +0100

Job Snijders wrote:
> 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

---

From: Di Ma <[email-masked]>
Date: Fri, 5 Feb 2021 13:13:03 +0800

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.

Di

> 2021年2月3日 00:56，Martin Hoffmann <[email-masked]> 写道：
> 
> Job Snijders wrote:
>> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops